Re: release 3.4.x

[Jordi Gutiérrez Hermoso]

On 8 September 2010 07:19, Ben Abbott <address@hidden> wrote:
> It was a bit of a hassle last time, but should be branch and then do
> parallel commits when needed?

Ideally, no? Only a release manager should hold the keys to the
release repo and should be the only person in charge of pulling
bugfixes from the development repo.

Alternatively, it can be more easily done the other way around: only
bugfixes should be pushed to the release repo, assuming everyone knows
what a bugfix changeset looks like. Normal development can still
happen in the development repo, and the development repo can
periodically pull and merge with the stable repo. The release
manager's task would then be stewarding the stable repo (e.g. strip a
mistaken bugfix) and pull and merge those fixes into the development
repo.

We can also do this without making separate repos, just making a named
stable branch. Here's a couple of descriptions of how to do it:

      http://stevelosh.com/blog/2010/05/mercurial-workflows-stable-default/
      
http://hgbook.red-bean.com/read/managing-releases-and-branchy-development.html#x_390

The Mercurial repository itself follows this release model. However, I
think you guys don't like branchy development? It's conceptually
slightly more complicated than having separate stable and development
repos and having the development repo periodically pull from the
stable repo.

If being a release manager only involves managing an hg workflow, I
can do it. If it also requires judging the quality of patches and
being intricately familiar with the codebase, then I can't.

- Jordi G. H.