Re: [boost] [test] boost.test owner unresponsive to persistent problems for multiple years

Subject: Re: [boost] [test] boost.test owner unresponsive to persistent problems for multiple years
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2015-01-09 01:32:17

On 9/01/2015 06:51, Gennadiy Rozental wrote:
> Jürgen Hunold <jhunold <at> gmx.eu> writes:
>> The main  issue seems to be the major refactorings in the
>> develop branch. It
>> is easy to blame the tool, but the new functionality should
>> have been develop
>> in a separate feature branch.
>
> When development started we were still in svn. I think we'll use this model
> from now on.

Just as a bystander comment -- I haven't looked into the specific issues 
in question here and what severity they have -- but what I've gathered 
from the thread so far is that the develop branch is in the middle of a 
long and winding refactoring/redesign that is likely to take quite a bit 
longer before it is all finished off and ready to release, and that 
several bugfixes (whether major or minor I don't know) have been caught 
up in this and held back from release as a result.

One of the nice things about git is that branches are just labels.  They 
carry no meaning beyond what you care to assign to them, and can easily 
be moved around.  In particular the only magic thing about the "develop" 
branch, as far as I understand it, is that the automated tests can be 
run against it.

This suggests a way out, if you want to satisfy both goals of quickly 
getting these bugfixes into a releasable state while also continuing 
work on the larger refactoring:

1. Rename the current "develop" branch to "bigrefactor" or similar.
2. Create a new "develop" branch from "master".
3. Cherry-pick or apply as new the individual fixes for whichever issues 
you want to get releasable.
4. Let the automated tests cycle and do anything else necessary to be 
happy with the fixes.  While waiting for automated tests or anything 
else you can continue working on the big refactor in its separate branch.
5. Once all is happy, merge develop to master.
6. Rebase "bigrefactor" onto the new master.  (Optional, but keeps 
things tidier, albeit at the cost of possibly annoying anyone else who 
has a clone of it.)
7. Either rename "bigrefactor" back to "develop" or leave it separate 
for future quick-fixes.

As to whether this is worth it for these particular issues -- well, only 
you can decide that.