[Biopython-dev] biopython on github

[Peter]

On Tue, Mar 17, 2009 at 3:45 AM, Chris Lasher <chris.lasher at gmail.com> wrote:
> 2009/3/16 Tiago Antão <tiagoantao at gmail.com>
>
>> I've been reading this thread and mainly staying silent but there is
>> one question that is not clear in my mind but I believe it is
>> important:
>>
>> How is the "official" biopython trunk controlled? Currently what is on
>> CVS is the gospel and Peter and Michiel essencially have control of
>> what is there and what is labelled as a "biopython distribution". How
>> will this work now?
>
> In a distributed workflow, there is no technical official repository. The
> "official repository" is socially enforced. Technically, there is no
> official repository of the Linux kernel anymore. However, there is an
> "official" version, which is Linus Torvald's repository. It is socially
> enforced. I think Michiel and Peter still head the Biopython project--at
> least they have the most clout, I would say. Therefore, we will probably
> look to one of their branches as the "official" branch of Biopython. When
> one of them wants to step down in duty, we will socially pass the torch on
> to the next taker.

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.

We could potentially continue to have a shared official branch (e.g.
belonging to the generic github biopython user), and give all the
existing CVS contributors write access - and continue to manage this
as before.  So for example, if Frank wanted to check in some minor
changes to Bio.Nexus he could just do it.  Future contributors
patches/branches might get taken up by a developer on a personal
branch for testing, before being merged into the official branch.

i.e. We can initially continue as before - right now I don't have a
feel for how much work the role of an official branch maintainer would
be, and it is difficult to guess without more hands on experience
using the new tools.

>> The second question, related to the first is how will different
>> branches (of different persons) be managed? I am seeing people
>> starting working on the same code in different directions and then
>> having problems merging everything together.
>
> People are supposed to work in different directions; this is the point of
> distributed workflows. Merging tends not to be so difficult, and compared to
> centralized models like CVS and SVN, it's a cinch. We will help provide
> documentation for proper merging habits (e.g., merge early, merge often, and
> no rebasing after pushing, etc.). There are also screencasts popping up (in
> particular Scott Chacon's re-make of his Gitcasts, now at learn.github) that
> we will link to for educational purposes. And of course, other developers
> will be around to help out in tricky merges.

Well, yes, in theory we have the same problem now with CVS - and while
the tools may make merging easier, some communication is essential
when working on the key modules which impact large parts of the code
base.

Peter