fenics team mailing list archive

[Jed Brown <jed@xxxxxxxx>]

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.