[Biopython-dev] biopython on github

[Peter]

2009/3/17 Tiago Antão <tiagoantao at gmail.com>:
> On Tue, Mar 17, 2009 at 8:46 AM, Peter <biopython at maubp.freeserve.co.uk> wrote:
>> I think it is essential we have a clearly labeled official trunk
>> (perhaps with branches for releases), which will be used for all the
>> official releases (tar balls, zip files and windows installers).  Our
>> main webpage should make this very clear.
>
> I agree.
>
> I would like to take this opportunity just to make my opinion clear (I
> normally tend to list hipothesis and refrain to give my own opinions).
>
> 1. I don't think there is a pressing need to go from CVS to whatever.
> While CVS is not perfect I don't think it has been a big hurdle. But
> if people want to go in that direction, I have no strong feelings
> against it also.

On a purely pragmatic level, yes, CVS has been enough.  This is one
real reason why there hasn't been a great deal of pressure on us to
move - it wasn't "broken" for how Biopython worked, although it does
make branching non-trivial.  Moving from CVS to a distributed version
control system (DVCS) won't make much difference for those of us with
CVS access - the big benefit as I see it is for potential contributors
who can easily make a branch to try out their ideas, and keep it in
sync with the master branch.  This could transform how new modules or
bug fixes get contributed, hopefully for the better.

> 2. The hurdle was that _policy_ was too conservative: Some time ago it
> was not acceptable even to consider a development branch. That
> stiffles things (although it ensures stability which is good).
> Fortunately things are more negotiatable now. The point is: the main
> issues are policy, not technology.

Historically Biopython has worked from a single stable branch (Brad -
can you comment about the history of this effective policy?).  I
recall saying something in the last year or so about not wanting to do
any branching in CVS while the SVN migration seemed imminent, but this
was primarily to avoid any complication in the migration itself,
rather than any deep objection to branches themselves.

> 3. Like it or not, different mechanisms (ie centralized versus
> distributed VCSs) facilitate different policies. Distributed version
> control facilitates branching to a massive degree.

True.

> 4. I think a middle ground is a good idea: While there is an official
> distribution (eg that one that is labelled biopython 1.50 and that
> will end up on most users computers) which is agressively controled,
> there should be space for people to try out new things.

I'm not quite sure what you mean by agressively controlled.  Moving to
a DVCS really should make public experimental branches much easier.

> 5. People that try out new things should be aware (to avoid
> disappointment) that their new code might not be accepted, for many
> reasons on the official trunk: not enough documentation, no test
> cases, design not acceptable, poorly-commented code, whatever. It
> would be very sad that people would start working on something, spend
> lots of time on their branch just to see their code refused to be on
> the "official" trunk.

That is a risk - especially if anyone were to go off and work in
complete isolation without even posting anything to this mailing list.

> So, in my view things work like this:
> A. The "official" version on biopython.org is controlled by a "head
> honcho", currently Peter with input from biopython-dev. This is the
> version that most users will ever see in practice.

That could work - although having anyone as a single bottle neck is a
risk, assuming you get someone to agree to the role in the first place
;)  I am generally happy with the current arrangement where module
owners have a degree of autonomy over their modules.  I wouldn't want
to have to approve every single minor change you (Tiago) make to
Bio.PopGen - but I suppose occasional review and merging of code from
Tiago's branch on request wouldn't be too onerous.

> B. The official version has a lot of quality enforcement on top.

What does that mean?  e.g. a strict policy about unit tests before
anything goes into the main branch?

> C. People should be free to branch away and try new things.

Given the Biopython license (as Leighton pointed out) this is already
the case with CVS.  Its just using a DVCS makes should this easier,
especially for keeping branches in sync with the official branch, and
hopefully for any merges back.

> D. People that branch away should be aware that their stuff might not
> be accepted on the official distribution. If they want it accepted
> they should come to biopython-dev and have a cup of tea with the
> community.

I agree.  I like tea.

> E. Maybe some contact points should be defined for modules?

Do you mean something more explicit about documenting who currently
maintains each module?

> F. People who want their code included in the "official" distribution
> should seriously think in branching from the "official" branch and not
> from any other.

I agree.

> I would really like to see an "official" git branch which should be
> created, in my opinion from a stable release and either by Peter or
> Michiel (or any other long term CVS-write user).

I think we'll have that - and in the short term the CVS mirror on
github can be used.

> In my case I would branch to maintain some of the PopGen code.

Great.

Peter