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.

I read up on the PETSc workflow and gitworkflows and think it looks
very good. I'll propose that we adopt the gitworkflows model (without
the 'pu' branch, at least initially).

One thing that I found confusing at first is that I felt the model
would lead to 'next' degrading over time - topic branches get merged
in for testing and those that don't make it to 'master' get stuck in
there forever. But this seems to be taken care of by the "rewind and
rebuild" of 'next' after release.

--
Anders