[Bioperl-l] git branches, tags, 'topic/bug_####'

[Chris Fields]

On May 13, 2010, at 7:42 AM, Jay Hannah wrote:

> ------- Comment #3 from cjfields at bioperl.org  2010-05-12 23:28 EST -------
>> Ouch, that's a bit nasty.  Taking advantage of git move and doing this on a
>> topic branch (topic/bug_3077) on github.
> 
> I plan on cleaning up the 'jhannah' branch (renaming it 'topic/bug_2515', asking people for their input, merging to master).
> 
> I plan on cleaning up the 'yapc10hackathon' branch. I can't remember what Robert and I left in there after YAPC last year.
> 
> Should most of the other branches be deleted? If a branch hasn't been changed in more than a year and no one intends to jump into it in the coming year what purpose does it serve? Old tags can hang out forever, but shouldn't our branch list be tidy? (Specifically I would argue that old release number tags should hang out forever, but I don't see the point in any other ancient tags continuing to exist if their purpose isn't documented anywhere.)

I would say err on the safe side and keep the ones we're unsure of, but a cleanup would be nice.  We could adopt what Moose has done and move branches we're unsure of to something like 'attic'.

> Are we serious about emulating this branching model?
> 
>   http://nvie.com/git-model
> 
> If so then we need to create a 'develop' branch and only the release manager should touch 'master' and yahoos like me should be branching off of 'develop' instead, right?
> 
> Counter argument:  Since 'master' is the default branch and we want to encourage doc patches and typo corrections from the world making trivial contributions as easy as possible for everyone, I would think that using 'master' as the daily headstream would be better. So 'topic/bug_####' for each non-trivial Bugzilla ticket, and release managers can work their magic in 'release-#-#' branches. (Release branches old enough that there's no way we're going to patch them any more are deleted, and only the tag remains).

...

> Thoughts?
> 
> Jay Hannah
> http://biodoc.ist.unomaha.edu/wiki/User:Jhannah
> 
> 
> P.S.  My "up to date" OS X 10.6.3 machines both had git 1.5.3.1 on them. Upgrading to git 1.7.1 makes branch checkouts simpler.

Moose has a 'stable' branch that release managers (the cabal) pull into from 'master' for releases.  It's just a matter of semantics, what name we use for active development branches and what to use for stable releases; for us, the 'develop' and 'master' from that link could be (respectively) 'master' and 'stable'.  'hotfixes' would be bug fixes, and 'feature branches' would be just that, new features to be added.

As for bug fixes, it would be much nicer to have most changes beyond very simple ones (including all bug fixes) relegated to branches that can be merged in.  This sequesters any changes to the branch, where they can be tested prior to a merge.  

Re: deletion of branches, I'm only really in support of deleting feature branches that have been merged back to 'master' or another branch (e.g. only removed using 'git branch -d foo').  Older subversion release branches don't tend to fall into that category, in that we had merged or cherry-picked changes from svn trunk to them, not vice versa; they were never merged back to trunk.  Deletion in this case would be somewhat history-revising, correct?

Saying that, we could adopt a workflow policy that allows deletion of any merged branch.  All this suggests coming up with a good 'Contributing' document.  Our 'Using Git' is a start towards this, but it's more a general use page and could point to other (possibly better) resources.  I would like something a bit more focused to demonstrate example work-flows and standard practices for those new to git and to BioPerl.  It should also mention how we handle pull requests and other github-related bits.

chris