Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk