[Biopython-dev] Developmental and experimental branches
tiagoantao at gmail.com
Sat Jan 10 16:48:03 UTC 2009
This whole discussion is very interesting. In fact, whatever are the
conclusions I think they should be labeled "offical policy" and put on
The biggest problem that I've faced is that, whenever I am doing
something, I don't know the level of acceptability with other
developers. I tend to put everything to discussion before I commit it
and whenever I say something I might get completely different answers
from time to time and from different people. The end result is that I
defer from commiting things because of issues that are raised in an
There should be a page clarifying things like:
1. Are contributions that have a small target audience accepted?
2. Use of foreign libraries (e.g., SciPy)?
3. Code management policies. Branches? Adding new code? Breaking interfaces?
4. New developers
5. Legal issues
6. Interop with non-free software
7. Code quality strategies. Code review? Testing?
8. Multiplatform issues
I am not saying a big document. But as questions arise, just discuss
them, arrive at a decision and document them. It becomes tiring having
to answer the same questions about code that you want to submit over
and over again and with different issues everytime.
One can live with decisions that are disliked, but it is much more
difficult to live when the playing ground is moving all the time.
On Fri, Jan 9, 2009 at 4:18 PM, Bruce Southey <bsouthey at gmail.com> wrote:
> 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
> 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
> 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
> Please add other issues.
> I would appreciate these issues being addressed when appropriate.
> 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
>> Biopython-dev mailing list
>> Biopython-dev at lists.open-bio.org
> Biopython-dev mailing list
> Biopython-dev at lists.open-bio.org
"Systems can remain irrational far longer than you or I can survive" -
Freely adapted from John Maynard Keynes
More information about the Biopython-dev