[Biopython-dev] Developmental and experimental branches

[Bruce Southey]

Hi,
In a previous thread (and indicated in others) it was suggested that 
perhaps Biopython needs some type of development  or experimental 
branch. So this thread is orientated to provide some discussion on this 
and considers that Biopython has moved to SVN. I think it is very 
relevant discussion because Biopython needs an effective approach to 
mainly handle new code but also handle significant rewrites of older code.

The most important question is do you support creating developmental and 
experimental branches or not?

However, I do not think that this is a yes or no answer and I am not 
concerned about the question at the present time.  Rather I am concerned 
about the burden placed on the maintainers (especially Peter and 
Michiel), the expression of the developer needs and how this impact the 
community. I am rather neutral on it (probably because I have not 
contributed any major code to Biopython) but I would like to ensure that 
the discussion leads to positive changes.

I find Biopython interesting and special for various reasons. There is a 
solid core of functions that are common to many aspects of 
bioinformatics. But it also contains very specialized code that has a 
much smaller audience. Consequently certain parts get considerable 
exposure and other parts get limited or no exposure. This means that it 
may be necessary to release beta versions in order to get the necessary 
exposure as I assume that code has had sufficient development to be 
released in the first place. Creating developmental and experimental 
branches is one way to get this exposure but perhaps branches are not 
necessary.

An alternative approach is creating specialized projects within 
Biopython that can be used for development and testing. For example, 
Scipy provides SciKits that are related code that is typically special 
purpose or is released under a different license than scipy/numpy. This 
replaced the sandboxes that existed in prior versions of numpy and 
scipy. But a recent problem arose in numpy was how to get code from such 
a location into numpy by creating a experimental section in the main 
distribution but that met some strong resistance.

Therefore, I see the following issues that need to be addressed 
regardless of the approach taken:

0) Must be easy for project maintenance and release as this must not 
create an extra burden to Biopython!
1) Ensure adequate testing is performed especially to get it out to the 
appropriate audience and to correct the code and APIs. I consider this 
rather important because I tend to follow a type of user experience 
design (http://en.wikipedia.org/wiki/User_experience_design) and 
software prototyping (http://en.wikipedia.org/wiki/Software_prototyping) 
for software development.
2) Stabilization of APIs for backwards compatibility as we don't want to 
change these with each Biopython release.
3) Adequate test coverage especially across platforms and different 
software versions. For example Windows paths and older software versions 
can cause problems on other peoples machines but not yours.
4) Some type of code review even if it is just to ensure a consistent 
format (like spaces versus tabs) or compatibility across Python versions 
and platforms.
5) If developmental or experimental branch are used then how does the 
code move into the main distribution and how are these branches created 
and destroyed.

Please add other issues.

I would appreciate these issues being addressed when appropriate.

Regards
Bruce

Peter wrote:
> On Wed, Jan 7, 2009 at 11:54 AM, Tiago Antão <tiagoantao at gmail.com> wrote:
>   
>> Considering that CVS has no development branch I think having git is
>> very good. I would just recommend extreme care with changing existing
>> code. When merging back into CVS, changes to existing code might not
>> go in (especially if they change interfaces) or be delayed.
>>
>>     
>
> If there is a strong interest in having experimental branches in the
> official Biopython repository, we could discuss that as an option.
> Although I would prefer we get moved from CVS to SVN first before
> actually doing this, in order to keep the migration as simple as
> possible.
>
> Peter
>
> _______________________________________________
> Biopython-dev mailing list
> Biopython-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/biopython-dev
>