[Biopython-dev] biopython on github

[Bartek Wilczynski]

On Mon, Mar 16, 2009 at 12:30 PM, Peter <biopython at maubp.freeserve.co.uk> wrote:
> On Sun, Mar 15, 2009 at 6:54 PM, Brad Chapman <chapmanb at 50mail.com> wrote:
>> - Pick a distributed source code management system. My preference
>>  is Git, only because it currently has more steam behind it.
>>  Git/Bazaar will likely end up being like the VHS/Beta debate.
>
> I would agree git has more mind share, but I have no technical reason
> to choose one over the other.
>
> In terms of read only access, having a mirrored trunk branch on both
> git (e.g. github) and bazaar (e.g. launchpad) is possible for
> evaluation purposes.

It is possible, but I don't know if we should do this. To some extent
having too much choice
might be problematic....

We've done some tests on both bzr and git and it seems that both can
do the job for us. I assume,
that the purpose of "test-driving" instead of directly switching to
git is to give us a possibility  to go
back in case things go really bad. But I don't think it's a likely
event. Bigger projects are using git
(or bzr) and doing fine, so we shouldn't have problems either.

On the other hand I don't expect that having the possibility to
test-drive two options is going to make the
decision any easier. I don't expect too many people to try both
options and even if it happens I don't think
there will be a clear acclamation that one is better than the other.
Honestly, we can't expect that all developers
will learn two tools just to help us choose... Even though I was
myself one of the proponents of switching to bzr
I think that we should focus on one option and git seems to be the one
with bigger mind share among biopythonistas.
So I would vote for dropping the discussion on bzr and focusing on
making sure that noone is left behind with their
problems during the (possibly not too long) transition to git.


>
>> - Test drive use of Git on an official GitHub repository. This would
>>  involve a few things ...
>
> Giovanni has shared the github "Biopython" user information so we
> (i.e. Biopython) can use that for any official presence on github -
> which is great.  Bartek and Giovanni seem to have this working OK.
>
> I think having the latest CVS trunk in Launchpad automatically is
> stalled because they (launchpad) can't cope with a simple
> username/password for accessing a remote CVS server.  Is that right
> Bartek?
>

Yes, we have now the biopython branch on github synchronized with CVS
on an hourly basis.
There is no problem with synchronizing a branch on launchpad in the
same script, but I didn't do it for reasons explained above.

>> - Evaluate the success of Git. This is easy to measure in terms of
>>  new contributors, increased happiness, and what not. At the same
>>  time we can monitor how GitHub evolves over time.
>
> It may not be that easy to measure in practice...
>
Well, If everyone will be able to use git I'd say it's a success. We
don't need a perfect solution. We
want to move to _a_ distributed version control system.

> I did have that same example in mind - having to depend on a third
> party like GitHub, LaunchPad or Sourceforge is great until things go
> wrong.  The Open Bio Foundation is much smaller, and while they don't
> have 100% uptime either, they are normally very responsive to issues
> because they only support a small number of projects.  Of course,
> ideally we might have both - an OBF hosted (git) repository on
> biopython.org, synced to github for people to enjoy its collaborative
> additions.
>

There is one difference between moving to sourceforge and moving to git.
With git, it is much less of a problem to switch hosting. The
fundamental idea is that every branch
(including all local developer branches) can be a "master" branch. So
switching to a different
hosting location is a matter of an e-mail on the developer mailing
list telling people to update
the location of the "master" in their branches. So I think that we
need to worry less about git
hosting than we would need to worry about cvs (or svn for that matter).

cheers
  Bartek