Subject: [Fenics] How do we do bugfix backporting now?

From: Martin Sandve Alnæs <[email-masked]>
Date: Wed, 10 Apr 2013 14:55:13 +0200

I've just pushed a critical bugfix to ufl on bitbucket, which should
be backported (cherry-picked) to 1.2. What's the procedure for this
now? Do we apply patches to the old lp series? Is there a 1.2 git
branch I can cherry-pick directly to?

Martin

---

From: Anders Logg <[email-masked]>
Date: Wed, 10 Apr 2013 17:29:14 +0200

> branch I can cherry-pick directly to?

There's no such branch. But if we decide to follow the gitflow model,
we should create a new branch called 'develop' inside the ufl
repository (the branch 'master' already exists).

All releases should be made from the 'master' branch and all
development in the 'develop' branch. Before each release, one branches
off 'develop' via a release branch and then into 'master'. Then after
the release, the release branch gets removed.

http://nvie.com/posts/a-successful-git-branching-model/

What is needed for a fix like this is to make a temporary 'hotfix'
branch off 'master'. So my suggestion would be to

1. Create the 'develop' branch (from 'master')

2. Create a branch 'hotfix-1.2.1' from master

3. Fix the bug there (cherry pick from 'develop')

4. Merge the fix into 'develop' and 'master'

5. Remove the hotfix branch

Steps 3-4 will be a bit different since you already made the fix in
'master'.

--
Anders

---

From: Florian Rathgeber <[email-masked]>
Date: Wed, 10 Apr 2013 19:32:38 +0100

> repository (the branch 'master' already exists).

Note that you can very easily resurrect any revision as any branch:
$ git branch <branch-name> <revision>

> http://nvie.com/posts/a-successful-git-branching-model/

The release branch only lives for as long as it takes to finalise the
release, at which point it is merged into master and that revision of
master is tagged with the release and the branch removed.

> Steps 3-4 will be a bit different since you already made the fix in

I wouldn't retrospectively try to hammer history into gitflow shape.
Instead I would tag e21d9f6 as release 1.2.1 and start gitflow from
there i.e. make this also the tip of the dev branch (so this revision
will the the last revision ever where dev and master will point to the
same revision) and only work on dev from then on.

# assuming you're on e21d9f6
$ git tag 1.2.1  # tag the current revision
$ git branch dev # create a new branch starting at the current revision
$ git push --tags -u origin dev

Florian

---

From: "Garth N. Wells" <[email-masked]>
Date: Thu, 11 Apr 2013 09:14:47 +0800

The PETSc developers have laid out their approach, which includes
fixes to releases:

    https://bitbucket.org/petsc/petsc/wiki/developer-instructions-git

Maybe we should follow their approach, and piggy back on their
easy-to-follow development model documentation? Over time we can
evolve our own workflow if required.

Garth

On 11 April 2013 02:32, Florian Rathgeber <[email-masked]> wrote:
> _______________________________________________
> Mailing list: https://launchpad.net/~fenics
> Post to     : [email-masked]
> Unsubscribe : https://launchpad.net/~fenics
> More help   : https://help.launchpad.net/ListHelp
>

---

From: Anders Logg <[email-masked]>
Date: Thu, 11 Apr 2013 20:27:00 +0200

Is there a difference between these three?

  git-flow
  man 7 gitworkflows
  PETSc workflow

Or are they all the same thing?

--
Anders

---

From: Jed Brown <[email-masked]>
Date: Thu, 11 Apr 2013 14:26:12 -0500

Andy Ray Terrel <[email-masked]> writes:

> Care to comment here?
>
>
> ---------- Forwarded message ----------
> From: Anders Logg <[email-masked]>
> Date: Thu, Apr 11, 2013 at 1:27 PM
> Subject: Re: [Fenics] How do we do bugfix backporting now?
> To: "Garth N. Wells" <[email-masked]>
> Cc: FEniCSMailing List <[email-masked]>
>
>

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
~~~~~~~~

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.

---

From: Anders Logg <[email-masked]>
Date: Thu, 11 Apr 2013 21:38:39 +0200

> 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

---

From: Anders Logg <[email-masked]>
Date: Mon, 15 Apr 2013 14:31:19 +0200

> 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

---

From: Jed Brown <[email-masked]>
Date: Mon, 15 Apr 2013 08:46:44 -0500

> rebuild" of 'next' after release.

Yes, also note that if a topic merged to 'next' is abandoned (e.g., you
decide it's not a good approach to the problem), you would revert it on
'next'.  If it's just not mature yet, it rides along in 'next' until a
release and then becomes part of the rewound 'next'.

At any point

  $ git log --no-merges master..next

shows all the commits that have not yet graduated.  If you use topic
branches on the server like PETSc or https://github.com/gitster/git,
then

  $ comm -12 <(git branch -r --no-merged master | sort) <(git branch -r --merged next | sort)

shows the name of all the topic branches that have not graduated.  I use
a combination of this and the decorated log command below to check for
stragglers.

  $ git log --graph --decorate --oneline --topo-order --no-merges master..next

---

From: Anders Logg <[email-masked]>
Date: Mon, 15 Apr 2013 17:20:57 +0200

>   $ git log --graph --decorate --oneline --topo-order --no-merges master..next

Thanks! I'll store those in my sack of git charms.

--
Anders