Re: [boost] git cherry-pick (Was: RE process (prospective from a retired FreeBSD committer)...)

Subject: Re: [boost] git cherry-pick (Was: RE process (prospective from a retired FreeBSD committer)...)
From: Steve M. Robbins (steve_at_[hidden])
Date: 2011-01-31 22:25:46

On Sun, Jan 30, 2011 at 07:55:10PM -0800, Steven Watanabe wrote:
> AMDG
> 
> On 1/30/2011 7:30 PM, Steve M. Robbins wrote:
> >On Sun, Jan 30, 2011 at 11:14:53PM +0000, Christopher Jefferson wrote:
> >
> >>I think the problem is having a "trunk" which is merged piece-meal
> >>into a release branch. This is an unusual method of development, I'm
> >>not sure of any other large projects which have the a long-lived
> >>trunk and release, with merges from trunk to release. git does not
> >>support this well.
> >
> >It's not just git, in my experience, but humans also have trouble with
> >this model.  One of the main problems being that bugs are fixed in the
> >trunk then languish, forgotten, while Boost is released with the same
> >bugs, sometimes for more than one release.
> >
> 
> I don't deny that the current system has problems,
> but it does exist for a good reason.

I'm sure you're right.  Moreover, upon reflection, I believe my issue
can be fixed in ways other than changing the merging model.  For
example, one could have an extra state in the issue tracker: open ->
fixed-in-trunk -> fixed-in-release.  Ideally, the latter transition
could be made automatically when the change set containing the fix is
merged.

Cheers,
-Steve