[Biopython-dev] Another Biopython release?

[Bartek Wilczynski]

On Tue, Sep 15, 2009 at 5:38 PM, Eric Talevich <eric.talevich at gmail.com> wrote:

> Sounds good to me. Completing the Git migration would make it much easier
> for me to maintain the Tree/TreeIO stuff, since I already have a few local
> branches based on it that an upstream CVS duplication would mangle.
>
Then maybe we should  wait with committing your changes to the time we
drop CVS,
in order to avoid loss of change history in your code... What do you
think, Peter?

>
> On Tue, Sep 15, 2009 at 10:59 AM, Bartek Wilczynski <
> bartek at rezolwenta.eu.org> wrote:
>
>> That would be great. As for the move to github, I've added some (quite
>> preliminary) docs for developers on how to make commits to the main
>> branch using git and github to the wiki:
>> http://www.biopython.org/wiki/GitUsage#Commiting_changes_to_main_branch
>>
>>
> The setup here for committers looks potentially different from the setup in
> "Merging upstream changes" (describing read-only tracking), but also
> potentially similar. Diff:
> - The github:biopython/biopython repository is called "official" here, but
> "upstream" there. Different protocol too, but that's intentional.

Yes, indeed. I know this might seem strange but I was trying to
deliberately make the distinction between the main repository in
read-write mode (official) and in read-only mode (upstream). I would
keep it like this at least for a while so that the transition from CVS
is as easy as possible. We have quite a few developers who are new to
git and comfortable with CVS.

> - It also shows how to treat the upstream/official repo as the origin,
> CVS-style.
Yes, exactly.
> This would mean the developer doesn't have a separate GitHub fork
> to use for personal branches, uncertain commits, etc. that don't belong in
> the main repo.
Not necessarily. It just means that these two roles are separate: a
developer can (but does not have to) have his own branch of biopython
tree where he/she makes the changes, but this is not directly linked
to the official (read-write) biopython branch. I know it's  not
necessarily the best way to use github, but I would like to avoid
getting people used to CVS confused. That's why I decided to describe
the role of developer with read-write access differently.

BTW, I would see the role of the GitUsage wiki page as a guide rather
than a law. That means that if someone understands better how to use
git and github and does not get lost with having in his both local and
remote branches with different origins I'm absolutely fine with this.
But I think it is quite complicated, especially for people new to git.

So, in summary, my idea was to (currently) recommend somewhat CVS-like
usage of git on the main branch, which would be simple for people to
use at first and encourage them to  create their own branches and do
development on them.

>
> Maybe a good way to organize the page would be in terms of how you want to
> use the repo:
>
> 1. Tracking Biopython with raw Git (without signing up for GitHub)
>   - git clone http://.../biopython/biopython
>   - remote: upstream
>   - how to format a patch and submit on Bugzilla
>
> 2. Tracking Biopython on GitHub (e.g. occasional contributors)
>   - sign up, click the "fork" button
>   - git clone http://.../your-name-here/biopython
>   - remotes: origin, upstream
>   - how to submit a pull request on GitHub
>   - how to add, manage and delete branches locally and on GitHub
>
> 3. Collaborating
>   - either #1 or #2 is fine
>   - how to add and manage more remotes
>   - how to apply Git patches, and why copy/paste kills kittens the next
> time you merge
>
> 4. Committing to Biopython
>   - same as #2, but use the private URL for the "upstream" remote
>   - remotes: origin, upstream
>   - policy on pushing upstream, code reviews, tagging, etc.
>
>

Having such documentation would be nice. I think that it is currently
structured more or less like that (now we just don't have #1 and #4
currently recommends a very simple CVS-like usage). I think that
adding #1 and putting in place policies on how to submit patches would
be great. For #4 I would vote for recommending (at least for a while)
the CVS-like way, but I'm absolutely for the development of the
alternative procedure, where the developer works with a single repo
both on his code and on official branch.

I don't want to underestimate the git skills of our current
developers, but so far I think only a few people have gotten their
github accounts, which means the simpler we keep it the better (at
least for a while). I certainly hope that people will get used to git
quickly, but I would like to make initial change for people who will
be switching from CVS to git as simple as possible.


cheers
  Bartek