[ome-devel] branch naming (fwd)

[Johannes Schindelin]

Hi,

my WISC personality is not allowed to send to this list...

---------- Forwarded message ----------
Date: Fri, 16 Nov 2012 18:39:09 +0100 (CET)
From: Johannes Schindelin <schindelin at wisc.edu>
To: Josh Moore <josh at glencoesoftware.com>
Cc: Curtis Rueden <ctrueden at wisc.edu>, ome-devel at lists.openmicroscopy.org.uk
Subject: Re: branch naming

Hi,

On Fri, 16 Nov 2012, Josh Moore wrote:

> dscho		joshmoore1: is there a good reason why you make explicit branches for 4.1, 4.2, 4.3, 4.4?			10:03
> ...
> dscho		joshmoore1: what you could do is to checkout <tag> and cherry-pick the relevant commits, then tag the result and push the tag. That's how you should do stable branches with Git.
> ---------------
> 
> 
> Curtis		Dscho asked me to paste some comments for Josh, so here they are:			10:35
> Curtis		josh: is there a good reason why you make explicit branches for 4.1, 4.2, 4.3, 4.4? What you could do is to checkout <tag> and cherry-pick the relevant commits, then tag the result and push the tag. That's how you should do stable branches with Git.			10:35
> Curtis		Probably we'll just email ome-devel about it.
> 
> 
> ---
> 
> All the branch naming concepts come from gitflow. The reason for
> choosing something so explicit even if different from much common usage
> was to have documentation and graphs about The One Way.

Well, I think it is time to rethink that silver bullet.

> There was also the command-line to make things somewhat simpler for our
> developers who were all completely new to git. The "4_4" branches are
> equivalent to "master" in the gitflow scheme. I've come to feel that the
> gitflow'ers really were only planning for web-style (and not necessarily
> library- or server-style) projects. Between that and the introduction of
> github, we've moved away from this to some extent, so a re-examination
> is certainly in order. However, as is so often the case with us, I'm
> hesitant to just change completely to another naming scheme, since it's
> now formalized throughout the whole team, it takes updating the docs,
> etc. A first step may be to just remove 4_4, etc but keep "develop"
> despite it's non-traditional-ness.

My suggestion is clear: replace the process (which in of itself requires
you to do more work, and which makes entry for newcomers harder than it
needs to be) by a simple one:

- master is the only integration branch

- topic-branches are identified by name, and if they fix a very critical
  issue or add something that downstream projects require in a hurry, do
  not require the 4-eye principle before merging. They will be reviewed,
  and changed when appropriate. There is a *lot* of precendent in at least
  bio-formats where things were fixed not quite completely but good enough
  for the moment, event after introducing the current, slow process
  (my claim is that the slow process does not fix what it inteded to fix).

- stable branches are either performed on detached HEADs (i.e. unnamed
  branches) and pushed as new tags, or if there are patches that do not
  require immediate release but should be staged for the next stable
  version, temporary release branches a la "for-4.4.6" are created,
  containing cherry-picked commits. Once the tagged version is pushed,
  these release branches disappear.

Yes, I claim that this would make things much, much simpler, and maybe a
bit more real-time again. Will be glad to discuss this approach, maybe we
can make it even simpler.

> Happy to move this to ome-devel.

D'oh, of course. Sorry for that.

Ciao,
Johannes