fenics team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Thu, Apr 11, 2013 at 02:26:12PM -0500, Jed Brown wrote:
> Andy Ray Terrel <andy.terrel@xxxxxxxxx> writes:
>
> > Care to comment here?
> >
> >
> > ---------- Forwarded message ----------
> > From: Anders Logg <logg@xxxxxxxxx>
> > Date: Thu, Apr 11, 2013 at 1:27 PM
> > Subject: Re: [Fenics] How do we do bugfix backporting now?
> > To: "Garth N. Wells" <gnw20@xxxxxxxxx>
> > Cc: FEniCSMailing List <fenics@xxxxxxxxxxxxxxxxxxx>
> >
> >
> > Is there a difference between these three?
> >
> >   git-flow
> >   man 7 gitworkflows
> >   PETSc workflow
> >
> > Or are they all the same thing?
>
> git-flow is definitely different, and I'm not a fan.  I've spliced this
> email with a rant I wrote to Aron, but first, let me summarize
> gitworkflows(7) and PETSc's workflow, which are very close.
>
> gitworkflows(7) is explained in the language of a patch-based system
> rather than a pull-request system.  They get patch series on the mailing
> lists and pipe the mailbox through 'git am' to apply patch series into
> local branches (these should always start from 'master' for new
> features, and 'maint' for bug fixes relevant to the last release).
> Patches frequently go through several revisions before being finalized,
> but in the meantime, Junio (the maintainer) puts promising-looking
> series into named topic branches and merges those into a throw-away
> integration branch called 'pu' (proposed updates).  Patches there will
> probably be reworked before they become permanent history, and 'pu' gets
> rebuilt frequently (every day or two).  It just provides an easy way for
> people to try out "everything anyone else is working on".  A throw-away
> merge into 'pu' lets you find out if your work might conflict with
> someone else's work without having to monitor the mailing list.  You can
> see all of Junio's branches here:
>
>   https://github.com/gitster/git/branches
>
> Only 'maint', 'master', 'next', and 'pu' are in normal repositories.
> When a topic branch is thought to be complete (perhaps after being
> re-rolled or fixed up in review), it is merged to 'next' where it
> undergoes testing for a while, then the topic branch is merged to
> 'master' ("graduation").  If everything graduates in a release cycle,
> then 'git log master..next' (shows what is in 'next', but not in
> 'master') would show only merge commits from when the topics were
> tested.
>
> I think this mailing list review and integration is among the best
> possible workflows for mature projects in which all participants are
> competent with their tools.  But it takes a lot of discipline to
> structure commits to be easily reviewable as discrete units and it
> requires using email clients that "behave".  In PETSc, we follow the
> same principle of testing in 'next' before graduating to 'master', but
> we don't have a sole "integrator".  Instead, we all push our topic
> branches to the same repo, which means that running 'git fetch'
> automatically gets everything anyone is working on.  Pushing a branch
> without merging it is just offering the opportunity for passive review.
> If we want review on something specific, we make a pull request.  A
> handful of us (mostly Barry, Matt, Satish, Karl, Peter, and I) have been
> doing almost all the integration, where "integration" is defined as
> merging to any of 'next', 'master', or 'maint'.
>
> I think this works pretty damn well, though Bitbucket doesn't have great
> features for pruning stale branches.  When someone clones the repo, they
> get all the topic branches by default, but they are remote branches so
> 'git branch' doesn't display them and 'git fetch --prune' cleans up.
> But when someone forks on Bitbucket, all the branches are cloned and
> there seems to be no dead-easy way to prune.  This is purely an
> interface tweak, but they don't have short-term plans to fix.
>
>   https://bitbucket.org/site/master/issue/6709/limit-which-branches-appear-in-a-fork
>
> Maybe if this workflow gets popularized, they'll fix the pruning issue
> (which is cosmetic rather than functional anyway).  It should be on GUI
> widget and a handful of lines of code, but alas, their site is not open
> source so we can't just add it.
>
> Note that you can use the same integration workflow with separate forks
> instead of having all branches in one fork.  Contributors that haven't
> established themselves with PETSc yet are working in forks now and
> sending pull requests.  This is fine, but we don't see what they are
> working on until they send a PR.  Less work for us, but sometimes people
> go down the wrong path and light review early on would help.  Of course
> you can always write the mailing list or even send a throw-away pull
> request just asking for comments.
>
>
> git-flow
> ~~~~~~~~
>
> http://nvie.com/posts/a-successful-git-branching-model/
>
> I don't like git-flow because it eschews the integration process that
> allows new features to interact before they are merged to 'master'.
> Instead of having topic branches tested together in 'next', someone has
> to be make the difficult decision of whether a topic branch that has
> only been tested in isolation should be merged into 'develop' (or
> hotfixes into git-flow's 'master', which is most similar to 'maint' of
> gitworkflows(7)).
>
> This generally means that a git-flow 'develop' is less stable than a
> gitworkflows(7) 'master', so it's more common to be working on a new
> feature and find bugs that were there when you started.  That's
> disruptive to development and its unpleasant to users that would really
> like the latest stuff that you think is actually ready for them to use.
>
> Thus any decision to merge a topic branch comes with the pressure that
> any bugs introduced in the merge (possibly through indirect semantic
> conflicts with other work) will disrupt any developer starting new work
> between the merge and the time a fix is provided.
>
> Also, when nearing a release, there are more places to start development
> ('master' for maintenance hot fixes, 'release-x' for bug fixes relevant
> to the next release, and 'develop' for new features that will not be
> merged until after the release).
>
> My perspective has been that 'maint'/'master'/'next', as described in
> gitworkflows(7), and eliding 'pu' for most projects, is simpler, produces
> cleaner history, and places less burden on the integrator to never make
> mistakes.  Nothing makes it to 'master' or 'maint' without first being
> tested _in combination_ with other new features in 'next'.  Since all
> new development starts from either 'maint' (bug fixes for maintenance
> releases) or 'master' (features relevant to upcoming feature release),
> bugs in 'next' only affect the integration process, not the development
> of new code.  Starting topic branches from a stable state is important
> so that you know that any new bugs are really your doing, and to prevent
> needing to merge from upstream in order to fix bugs introduced prior to
> starting your topic.
>
> I have yet to see an explanation of any benefits that git-flow provides
> relative to gitworkflows(7).  It is better than unstructured development
> without topic branches, but I think it has only received attention
> because of the nice graphic.

Thanks for this incredibly long post! I trust your judgement on this
and agree that the very nice graphic for git-flow does a good job of
selling it.

I'll read up on gitworkflows again (only glanced through it earlier)
and comment later.

--
Anders