Re: [boost] Merge procedure to master

Subject: Re: [boost] Merge procedure to master
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2015-01-24 02:48:30

Le 23/01/15 22:43, Barend Gehrels a écrit :
> Hi,
>
> Robert Ramey schreef op 23-1-2015 om 21:05:
>> Peter Dimov-2 wrote
>>> Robert's perspective here, FWIW, is that he develops and tests (quite
>>> extensively) in a configuration in which all libraries are on their 
>>> master
>>> branch and Serialization is on develop.
>> Thanks for pointing this out. This is true and of course a big reason 
>> that
>> for me the merge from develop into master IS trivial.  Sorry I forgot to
>> (re)mention that.
>
> You forget to point out all the other actions I mentioned in my list.
See below.
>
>>
>>> On this configuration, once everything is green, merge is as easy as
>>> "merge --no-ff develop". You've already tested it, so there's no way
>>> anything can fail.
>> correct, that's why I do it this way.
>
> And it is dangerous.
>
> Unless you're not dependant on any other Boost library.
>
> If you (with e.g. library Y) always work on develop and test with 
> other librarys on master, you don't notice any other development or 
> possible problem. Suppose you are dependant on library X. As soon as 
> the schedule comes out, moment S, you merge again because it is 
> trivial (moment T) , and you go on holiday.
>
> Library X decides (at moment M, long before S), to change a 
> return-type into something much better. 
This is a breaking change. This kind of changes should be introduced 
smoothly when possible. If the breaking change is intentional, the 
change should be done on a feature branch and announce should be sent to 
the boost ML in order to get an agreement when this can be done.

I'm not saying that this doesn't happens when the breaking change is not 
intentional, however when it is intentional it shouldn't as we have mean 
to avoid the trouble.
> You are using that feature. It happens. As soon as the release 
> schedule comes out, they stop developing, monitor regression matrix 
> (for library X), and after a couple of days, just before the closing 
> of master, they merge (moment U, after T).
Right. Maybe library X maintainer can run the tests of the its dependent 
libraries. Even after delivery the maintainer can take a look at the 
regression of its dependent libraries, such as Y
>
> Now your library is broken. It does not even compile anymore. You 
> don't see it, because you are on holiday and have done the job. Even 
> if you are not on holiday, you might not notice it immediately, 
> depending on how often you compile. And the masterbranch closes... 
> They don't see it because they run library X unit tests and not 
> library Y unit tests. It will be found by the users of the RC though.
>
> Of course it is not your fault! Why the xxx did they change the 
> return-type? But it is better... even you have to agree with that. And 
> they did it already at moment M and they did send a notification to 
> the Boost mailing list (which by chance you did not read).
>
> If you had used develop for your developments, you would have noticed 
> the breaking shortly after moment M already.
Don't forget that you were on holidays ;-)
>
> So it can be dangerous. Chances are low, but it happens.
>
> Another scenario, but I will not make it too long: library Z has a new 
> feature you really need! Do you wait until they merge to master? 
> Maybe, indeed, that is good practice. But it happens that another 
> library uses it already earlier than that... both on develop.
>
I will suggest that any use by library Y of a new feature of a library X 
must be done on a specific branch. The test on this specific branch can 
use the develop branch of X. Only when the needed feature of X is on 
release branch you can start merging the branch to develop.
>
>>> Of course this has its own drawback - the boost.org tests do not 
>>> work in
>>> such a manner.
>> True again! But I don't think this is a reason why I shouldn't do it 
>> for my
>> own tests. My life is so much easier since I started doing things 
>> this way.
>> Much of the back and forth cited above just goes away.
>>
>> Barend - Why don't you try my approach as an experiment.  It's super 
>> easy
>> to set up.  And if you don't agree that it makes your life a lot easier,
>> it's just
>> as easy to switch back. Try this an let us know how it works out for 
>> you.
>
> The approach is not so much different. You work always on master, I 
> always on develop. And sometimes (indeed) I check on master too, by 
> the way, without immediately merging afterwards.
>
> But please react on the other points on the list too. Do you monitor 
> the regression matrix? Wait for a couple of days? Or maybe it is not 
> necessary for you? As I earlier point out, we have multiple people 
> working on the library daily. You state that that makes no difference 
> - is that really true? Do you neatly update the docs every time you 
> merge with master?
>
Barend, I agree that having several authors/maintainers needs some kind 
of synchronization/communication and more rigor. It is up to the team to 
ensure that you do it well. Maybe have an integrator that ensures the 
sequence of deliver to develop/monitor  the regression matrix/fix/merge 
to release is respected. Other alternatives are of course possible.

Nevertheless I think that merge to master as soon as possible is better 
than delaying just before the release schedule has been announced. I'm 
not saying that the release schedule shouldn't be more deterministic as 
it was supposed to be.

HTH,
Vicente