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: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2015-01-09 01:48:30

Le 09/01/15 07:32, Gavin Lambert a écrit :
> 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.
>
+1
Vicente