Re: [boost] Merge procedure to master (was: Release sponsorship (was: Re: Boost 1.58 schedule available?))

Subject: Re: [boost] Merge procedure to master (was: Release sponsorship (was: Re: Boost 1.58 schedule available?))
From: Barend Gehrels (barend_at_[hidden])
Date: 2015-01-23 13:16:56

Robert Ramey schreef op 23-1-2015 om 7:47:
> As a reminder - I maintain that the merge from develop into master is 
> a trivial operation. If anyone is finding this not to be the case, 
> they are not doing right. 

> My proposition is that merging from development to master is
> trivial operation.  If it isn't for you, then you're doing something
> wrong.  The difficulties or peculiarities of any particular library are
> irrelevant to my view and my argument.

> LOL - one might say it's special.  But merging one's current develop
> branch into the master is a trivial operation.  If it's not then he's
> doing wrong.
>
> Or possibly when he says "merging the develop branch" into the
> "master" he's referring to other stuff like debugging code while it's
> in develop or who know what else. This other stuff has nothing to
> do with merging the develop branch into the master branch.
> LOL - we're not communicating.  merging develop into master should
> require absolutely no coding.  At the end of the operation for the library
> in question the code in the master should be bit for bit identical to
> code in the develop branch - that is all that the merge does.
> (could be a slight simplification if multiple authors are working on
> the same library and the authors are conflicting - but would be an
> extremely rare case here so I'm ignoring it).

Apparently you are quite convinced that merging to master is trivial. It 
is *not*.

First you have to convince yourself the regression matrix on develop is 
green, or the non-green cells are explainable. Then you have to be sure 
that all the recent commits, merges and pull requests are reflected in 
the regression matrix. That might take a couple of days, so preferable 
people have to stop with all changes on develop, a few days before 
merging to master. Requires planning and communication.

* (see below)

Then you have to be sure your master is up-to-date, pull, update sub-modules

Then you have to build and unit-test your to-be-merged code (on develop) 
where all other libraries are master-branch: it might break because of 
changes in other libraries. That can take several minutes up to more 
than an hour (depending on the size of the library and unit test coverage).

Hopefully all unit-tests pass! If not, you really have to find the 
cause, and take action (update renamed headerfiles, read 
documentation/updates, read the boost mailing list, communicate to the 
list (if the problem is in another library) or your team (if the problem 
is in your library or in the changed usage of the other library). You 
cannot merge as long as there are failures.

Maybe it is not your fault that it fails! Maybe there is a dependancy on 
updates of another library, or on Boost.Test. Then that library should 
be merged to master first. You then have to wait until that is merged 
(or remove the dependancy).

Also compile the documentation! Boost.Build or some other doc-tools 
might have been updated on master.

Ideally you do this on at least two platforms or compilers.

Assume all tests pass. Then you can merge to master! This part is indeed 
trivial.

Is there anything redundant in this list?

Be sure to check the regression matrix on master the few days after merge!

*Additionally preparing for a release (master), all release-notes have 
to be up-to-date, all documentation has to be up-to-date and reflect the 
last changes in the library, etc. Of course this should be done 
on-the-fly, while developing, but sometimes those things are a bit 
behind. I put this apart because it is not really part of the merge 
process and ideally should not be necessary.

This is why I prefer to merge only once per release.

Regards, Barend