Hi Rene, Rene Rivera schreef op 21-1-2015 om 16:19:

On Wed, Jan 21, 2015 at 5:06 AM, Barend Gehrels wrote:

...

Hi,

Boost 1.57 was released last November 3, so it is probably about the time to merge to master again?

Well.. You should merge to master when you think your libraries are ready for release. This is something that is almost entirely under your control.

Yes I know. We are co-working with 5 people on our library, resulting in net more than 2 full-time. So we have to plan a moment on which all current tasks are finished and we can safely merge it to master, before starting the next tasks in develop or other branches. To plan that moment, or possibly several of those moments, a schedule certainly helps!

Is there already a schedule available? Not yet.

OK, I hope there is one soon. Thanks, Barend

Hi, Olaf van der Spek schreef op 21-1-2015 om 18:09:

On Wed, Jan 21, 2015 at 5:00 PM, Barend Gehrels wrote:

...

We are co-working with 5 people on our library, resulting in net more than 2 full-time. So we have to plan a moment on which all current tasks are finished and we can safely merge it to master, before starting the next tasks in develop or other branches.

To plan that moment, or possibly several of those moments, a schedule certainly helps! Shouldn't you do (big) tasks on branches and merge those when ready?

Is it so weird to ask for a schedule? It seems I'm the only one asking this for each release again and again, we really need it. Besides the merging, for which I still think can use a schedule, there are also people using our library, asking when the new version is available, and what's in it. Based on the last version 1.57, of which a schedule was announced on September 29, and which this was one of the dates: * 13-Oct Last day for significant changes and based on a 3-month scheme, we are already late. Regards, Barend

Olaf van der Spek-3 wrote

On Wed, Jan 21, 2015 at 6:25 PM, Barend Gehrels <

barend@

> wrote:

...

Is it so weird to ask for a schedule?

Hi,

No, it's not. And I've no idea why Boost is 'struggling' with the release schedule so often.

Hmmm - could be that it's a volunteer effort which and only be done when some volunteer has the time to invest? Maybe it's time for some new ideas? Perhaps we can create a "Release Sponsorship" program whereby a company which really believes needs the updated "integrated" release can sponsor it with a cash contribution. The release would carry naming rights so a company with name like "survey monkey" could call it the "monkey" release with a link to it's website. Bidding would start at $1000 with 50% going into the Boost General fund and %50 going into the release manager's general fund. Certainly if having the newest integrated release isn't worth $1000 to any company on the whole planet, it's not worth a release manager's time to deal with all the hassle making and distributing a new release. Just a thought. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-1-58-schedule-available-tp4671426p4... Sent from the Boost - Dev mailing list archive at Nabble.com.

On 21 Jan 2015 at 15:23, Robert Ramey wrote:

Maybe it's time for some new ideas? Perhaps we can create a "Release Sponsorship" program whereby a company which really believes needs the updated "integrated" release can sponsor it with a cash contribution. The release would carry naming rights so a company with name like "survey monkey" could call it the "monkey" release with a link to it's website. Bidding would start at $1000 with 50% going into the Boost General fund and %50 going into the release manager's general fund.

Certainly if having the newest integrated release isn't worth $1000 to any company on the whole planet, it's not worth a release manager's time to deal with all the hassle making and distributing a new release.

You probably were being tongue in cheek Robert, but if not then this might be the second time we are in complete agreement this week! Next thing might be pigs flying! Regarding releases, they are highly disruptive to the develop branch as basically one has to down tools on feature work and spend an age iterating fixing up master branch such that all the other master branches in all the other submodules play well together on all supported platforms. For quickly moving libraries such as Thread, I can see four weeks per release being lost. Increasing release frequency increases that cost substantially. Hence I do wish there was a facility for sponsors to sponsor a merge of develop to master. If this had been the case for Boost.Test, would its develop branch have remained unmerged for so many years? No, I think someone would have done the merge if $5000 were on the table for it. Also, I think there is some scope for some libraries to be released quicker than Boost central. One could target the last released major Boost release - now we have git submodules, one simply swaps out the module and rebuilds the headers and docs. Unofficially in AFIO I have been supporting combining it with any Boost release since the first modularised one. It has macro logic which adjusts what it does according to the Boost version it detects. I may drop that support at some point, but it's food for thought. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 22 Jan 2015 at 9:58, Robert Ramey wrote:

...

...

Certainly if having the newest integrated release isn't worth $1000 to any company on the whole planet, it's not worth a release manager's time to deal with all the hassle making and distributing a new release.

You probably were being tongue in cheek Robert, but if not then this might be the second time we are in complete agreement this week! Next thing might be pigs flying!

I'm very serious about addressing this particular suggestion and about evolving the boost revenue (or lack there of) model. I'm aware that this is a very difficult problem that won't be solved with just an idea.

Wow. We were in agreement then. I always felt the Community Maintenance Team should have been configured as a bounty based system. If someone needs an unmaintained library to be maintained in some way, then they stump up a bounty for it. Note by unmaintained I would cast the net to include libraries with maintainers, though in that case the maintainer gets a veto. I also think the maintainer should get first dibs to the bounty too, they already have thankless jobs. This could be seen as creating incentives to not maintain libraries. I'm happy with that - software is expensive. I wouldn't go so far as holding users to ransom for fixes on payment though.

...

Regarding releases, they are highly disruptive to the develop branch as basically one has to down tools on feature work and spend an age iterating fixing up master branch such that all the other master branches in all the other submodules play well together on all supported platforms.

For quickly moving libraries such as Thread, I can see four weeks per release being lost. Increasing release frequency increases that cost substantially.

If this is the case, then something is not right and needs to be addressed. It's hard for me to comment on your particular case without spending a lot of time looking at the details, but I can speak from the experience of maintaining the serialization library over many years through several different Source Control systems and several different workflows. My current view is that our issues with with these things are now largely solved and we are in a good position to take boost to the next level - whatever that might.

With respect Robert, Serialization has nothing like the amount of code intricately dependent on it behaving exactly in some way, including in ways it was broken in the past. Thread offers no less than four versions of a threading API with often individual switches for mashing up API version features. Some of those API versions are intentionally broken to retain backwards compatibility with code written to assume that brokeness. It gets even better: some users want the old broken APIs to be C++ 11 aware, even C++ 11 capable. I remember a bug last year where the wrong constructor in a legacy API was being called under C++ 11 because the 11 rules are subtly different from 03 due to rvalue refs being around. One fun part is that parts of Boost were written for a different Thread API version than other bits, so when you compile all of Boost Thread has to be all things to all comers. This is a very brittle situation to be in. Hence the costs of doing a release. Right now Thread defaults to v3 of its API because v4 of its API, the current one, breaks parts of Boost. As I have often mentioned here, the ability to mark non-upgraded libraries for official deprecation and removal would be an enormous time saver for everybody else forced to work around them. It shouldn't be the case that the maintainers of Thread must go fix unmaintained Boost code nothing to do with Thread.

I work on my own schedule. I work on my development branch and test there. When it's passing ALL tests, I merge into master. the master branch of the serialization library is always ready for release as far as I know. That it is a strict improvement over the previous version of the master branch and has no known regressions. The timing of the "official boost release" is irrelevant to me. I think that anyone who has to know the release date is not doing things the way I'm doing and that they should start doing it that way.

I do the same, but my codebase like yours was designed around making maintenance easy for me. Thread is very old, some of it is quite creaky, and almost all of it was designed around a Boost which hasn't existed in a decade. Even its unit test suite reflects at least three different testing paradigms. Historically the test coverage was very poor, but this past year especially has seen enormous contributions of additional tests. The problem more recently is we need to disable quite a few of them simply to run the testing in a feasible timespan. I recently looked into running a regular CI unit test run for Thread, and I estimate it would take most of a day, enough to mean I couldn't run it nightly. For example recently Boost.Test made an update and broke a ton load of Thread. It turns out that Thread hadn't been configuring Test correctly for years, but the point remains that Thread is very sensitive to changes anywhere else in Boost.

...

Hence I do wish there was a facility for sponsors to sponsor a merge of develop to master. If this had been the case for Boost.Test, would its develop branch have remained unmerged for so many years? No, I think someone would have done the merge if $5000 were on the table for it.

Again, if merging from develop to release is a big problem, someone is doing something wrong. It should be almost trivial. As such it doesn't need any financial incentive. In fact, financial incentive would be the worst thing - it would be encouraging the continuance of a some sort of broken workflow.

master branch is special with Boost though. It's not just the "unit tests pass here" branch, but also the branch used to generate Boost release. That means writing code and merging is 50% of the effort of merging develop to master. I finished AFIO v1.3 some weeks ago, but I haven't merged from develop to master yet despite all unit tests being green apart from Mingw32, which I am going to drop support for (Mingw-w64 works, Mingw32 is just horribly broken). That's because for a merge to release branch I have yet to do: 1. Update documentation to reflect the new facilities, and indeed your Incubator review where I believe I have addressed the majority of your concerns at least partially. I've been at this for nearly three weeks now. You only get so much time outside of work. 2. Rewrite the design rationale as it is now quite stale given my recent empirical testing findings. 3. Add unit test targets for Android 5.0 which now supports C++ 11. Fix any failures. 4. Add more tests to improve line coverage as I know it's dipped below 90%. 5. Run compilation time benchmarks on all platforms. Fix any regressions. You might think this easy, but AFIO has about twenty different build configurations now. 6. Run performance benchmarks on all platforms. Fix any regressions. I had been hoping to merge to master for end of January, it's currently looking like mid-February.

Personally I think the problems of "maintenance" are over stated. If maintaining (as opposed to adding features) is a lot of work, one needs to step back and look at what he's doing wrong and think about how to change it.

I think a huge amount depends on how legacy your codebase is and how tightly other people's code depends on yours being exactly as before. I'll put it another way: QNX and Microsoft expend enormous resources making sure all future versions of their software have identical behaviour to before when in some form of compatibility mode. There is a big customer demand for that sort of "reliability", and people willing to pay serious bucks for it.

One final thought. How about using the "surprise release" © model? This one is someone looks at all the test matrices for all the libraries. When they (almost) all look good. The release is announced and the release branch is closed to updates except for any pending errors. No new features, etc. The the release is no work for developers at all!!!! I know this sounds like I'm trying to be funny, but I consider this a serious proposal.

I am not a fan of this model. The Web 2.0 culture does this a lot, but they provide services which can and are remotely updated if showstoppers turn up. When you ship a library on the other hand, that release is probably going to turn into stone in someone else's code. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

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

Peter Dimov schreef op 23-1-2015 om 19:30:

Barend Gehrels wrote:

...

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

While I don't disagree with your list, I have to point out that, in case of interdependent libraries, if everyone followed your lead and never merged to master, you wouldn't be able to test your changes against their master as you wouldn't know what it would be.

Or, to be clearer:

...

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.

If the other libraries do not keep their master branches up to date, you will have no way to test your to-be-merged code against their master branches.

So, in practice, if everyone merged once before release, at the same time, we'd be having the usual chaos where nothing works and the release managers need a month to figure out why.

While a merge to master can be painful in that interdependencies can cause unexpected failures, it is still - arguably - better to learn about these as soon as possible and fix them gradually over the course of normal operations, instead of during one protracted pre-release march.

Which is why I merge to master sooner rather than later. Of course, there is no single optimal strategy. For core libraries, specifically, on the one hand, you can break the world if your master doesn't work, on the other, nobody else can merge to master if they depend on your changes being merged first.

Thanks for the addition. I see the problem. From Boost.Geometry perspective we're on the dependant side, and that might be reflected in my list indeed. However, if we merge blindly, ignoring errors, for example once per week, that would feel really uncomfortable to me, and would it really help? Barend

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.

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.

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. I've talked to Rene about changing the boost.org tests to work in the way I do it. He appreciated the idea - but was concerned about the difficulties or implementing it on all the libraries one by one. I'm still convinced that testing each library in develop against all the others in master is the way to go - but since Rene does the work, he get's to decide. That is the boost way - as it must be. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-1-58-schedule-available-tp4671426p4... Sent from the Boost - Dev mailing list archive at Nabble.com.

Barend Gehrels wrote

Hi,

Robert Ramey schreef op 23-1-2015 om 21:05:

...

...

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

Peter Dimov-2 wrote 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.

...

...

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.

why? (btw - I don't use the --no-ff")

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.

That's a good thing!!!. I've the are libraries are in develop - they are not certified correct. If I test against the I get my failures along with everyone else's - and I have to sort them out by hand - which takes a lot of time as you've noticed. My way of doing things is more of a controlled experiment - I'm testing one thing (the serialization) library at a time while holding all the other variables (all the other libraries) stable. It's more accurate view of what I want to test.

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.

when library X comes out (is merged to master) - I don't merge - I update. If I then run my tests and there is a new error - I know it's the other guy and I can tell him. Note that my tests are not setup to test everyone else's stuff - they assume that the pre-requisite libraries are working. If I don't know that - then my tests are pretty useless.

Library X decides (at moment M, long before S), to change a return-type into something much better. You are using that feature. It happens.

If he does this in the master, he's made a mistake in a public interface. I'll have to give him a hard time if I detect it. But I can't be expected to be able to debug everyone else's stuff. 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).

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.

all correct - but at least the error is obvious. The boost release manager will have to decide to ask to role back a breaking change or the rest of to adjust to it. The benefits of detecting this earlier are no where no near the costs of testing against all other libraries which are not known to be in a bug free state. 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.

possible - but unusual. Again not worth the pain of chasing down everyone elses mistakes - which they likely know about anyway.

...

...

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 work on develop for the serialization library and the master for everything I need but don't have responsability for.

I always on develop. And sometimes (indeed) I check on master too, by the way, without immediately merging afterwards.

I can tell you from personal experience that my way of doing things saves a huge amount of time. I used to do it your way - but never again!

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?

I need to check develop to look for failures in compilers I don't have - but that's about it. If things are stable for a couple of days, I then merge to master.

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?

Git modularization supports the "feature branch" very, very well and very conveniently (especially with a GUI like SourceTree). I use it even though I'm working by my self. Each of your five people should be using a different branch. The should test against all the libraries in master and your library in develop. But they should only update their version of develop between times they're working on their feature. (subject to coupling problems of course). Anyone who has his feature working can merge into develop and let then let the rest of the team test it. The team leader - whom I presume is you - can decide when to merge develop in to master. I agree this situation doesn't dovetail that well with boost.org testing.

Do you neatly update the docs every time you merge with master?

No, I update the docs BEFORE I merge to the master. That is after it passes all the develop tests and before the merge so he docs are always in sync the code. And I don't even use DOxygen! Theres another think I do - I increment the serialization library one feature at at time. when it works I merge it all the way through to the master. I may have a couple of features going at once because some urgent thing comes up while I'm working on something else. The upshot is that I'm basically always working on one thing at at time and pushing all they though to the master before I add the next thing. This diminishes wasted time by a huge factor. BTW - i've got almost 300 tests to watch. But really compared to what I was doing before - this is so much easier, and effective. I urge everyone to consider it. And remember - it's not a commitment - it's just a workflow which can be easily changed if it doesn't work well for you. I really don't dispute the other points. its just that my of doing things results fewer iterations so the other issues are less problematic. For example I do wait a few days looking at the develop tests - if there's a bug I know its not mine but I keep an eye on it anyway. Of course I would prefer that the develop test matrix worked they way I work but it doesn't so I just live with it. My way is still better so I use it. No one seems to care - or even notice. No one has complained to me that I'm not testing their stuff.

...

I've talked to Rene about changing the boost.org tests to work in the way I do it. He appreciated the idea - but was concerned about the difficulties or implementing it on all the libraries one by one. I'm still convinced that testing each library in develop against all the others in master is the way to go - but since Rene does the work, he get's to decide. That is the boost way - as it must be.

I don't know the details of that. Merging multiple dependant libraries is a complex thing, which can go wrong in many scenarios.

Altering your workflow would make it much less burdensome.

That is why I thought that it was good to react on your statements that it is trivial.

No problem, I appreciate another opportunity to make my case!

Things can be solved, and we can do our best efforts to do it as good as possible, but it is not trivial.

OK maybe trivial is too strong - but not by much. Honestly, taking best advantage of our newer tools has made the job of maintaining the serialization library much, much easier than it used to be. But one has to change his practices. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-1-58-schedule-available-tp4671426p4... Sent from the Boost - Dev mailing list archive at Nabble.com.

Hi,

Robert Ramey schreef op 23-1-2015 om 21:05:

...

...

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

Peter Dimov-2 wrote 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

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

Le 23/01/15 22:43, Barend Gehrels a écrit : 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. 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

On Fri, Jan 23, 2015 at 7:30 PM, Peter Dimov wrote:

Which is why I merge to master sooner rather than later. Of course, there is no single optimal strategy. For core libraries, specifically, on the one hand, you can break the world if your master doesn't work, on the other, nobody else can merge to master if they depend on your changes being merged first.

Ideally such updates would be merged atomically, though that might be rather difficult. In theory it might work with something like Debian testing and unstable package repositories. Updates are uploaded to unstable and they only propagate to testing if the result in testing would be 'good'. An updated (and breaking) core pkg wouldn't go into testing until all packages depending on it have been updated too. -- Olaf

Barend Gehrels wrote

Is it so weird to ask for a schedule?

It seems I'm the only one asking this for each release again and again, we really need it.

I'm guessing that your the only one because your the only one that needs this. So the interesting question is: why doesn't anyone else seem to need this? I don't need it because the boost serialization library master branch is always in form ready to release (as far as I know). That is, it has less bugs and/or more features than the previous version (again as far as I know). Of course I can't say the same for the develop branch - that's why it's the "develop" branch. The boost git branching model has mostly solved long standing problems that we've traditionally had in this area. But it pays to tweak one's development practices to take advantage of it.

Besides the merging, for which I still think can use a schedule, there are also people using our library, asking when the new version is available, and what's in it.

I believe that your best answer to this question is: "we expect feature X merged into the release (master branch) on date X. So any boost release subsequent to date X will contain this feature" If this is not soon enough for your purposes you have a couple of options a) download/cloan the version in the release branch yourself. b) ask the boost deployment team to schedule an official release by date Y. So this get's the monkey of your back. If you've got 5 team members working on your library (congratulations!!!) then I would suggest that you consider tweaking your development practices in the following way. ( I know this may sound pedantic and/or patronizing, but please indulge me for the benefit of others) Each team member does the following: a) start with modular boost download from git repo. Set to master branch. b) On your library - switch to development branch and make sure it builds/runs all tests with bjam c) Create a local branch - if your name is george - you can call it george. d) make your changes in the source code and re-run the tests e) if your not satisfied with the new changes go to c) above f) switch to the develop branch g) merge in changes from branch george. h) If your paranoid (as I am), you can re-run the boost build tests on the library. i) Notify the team leader that you're going to push changes to the develop branch. The team leader might ask you to hold back while some other issue on the develop branch get's addressed. But he shouldn't have to do this very often, if ever. j) push your current develop branch to the git repo. k) keep an eye on the develop branch tests. The team leader can merge the develop to master (release) when he feels that the library is in a state such that he feels comfortable unleashing it upon the world. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-1-58-schedule-available-tp4671426p4... Sent from the Boost - Dev mailing list archive at Nabble.com.

On Thu, Jan 22, 2015 at 12:36 AM, Barend Gehrels wrote:

However, I'm still feeling a bit worried that as soon as I ask for a schedule, which is really about time in a 3-months release cycle, several people start to give me advices to change our way of working...

About the people asking for release dates, these are from large organizations. They want official releases, not just a trunk or a clone of a master.

Well, I guess that depends on the organization. Google, for instance, is known for using various degree of bleeding edge in its products. Anyway, there are no big companies behind Boost, so everything happens here more or less when the stars align, be that for good or worse. I don't mean to say you're wrong asking for a schedule (that'd be nice, actually), but you have to take into account how things work in practice. From that perspective adjusting your workflow might have its merit.

Peter Dimov schreef op 21-1-2015 om 23:04:

Barend Gehrels wrote:

...

However, I'm still feeling a bit worried that as soon as I ask for a schedule, which is really about time in a 3-months release cycle, several people start to give me advices to change our way of working...

You should wait for an "official" answer from the release managers, I suppose. They may need to discuss this among themselves first though.

Sure, I understand that. I was just answering the answers I got on my request. But for the rest I patiently wait. Regards, Barend

Hi Robert, Op 22 jan. 2015 om 00:31 heeft Robert Ramey het volgende geschreven:

Barend Gehrels wrote

...

Thanks for your amusing answer. It is appreciated.

Hmmm - I wasn't trying to be humorous - oh well.

...

About your proposed way of working - right, that is partly how we work.

OK - How about we create a release tomorrow at 5 PM then. Would that work for you?

Because you ask, I don't know how serious, I answer. 5 PM your time or my time? Our matrix in develop is pretty green. So I can merge, though I prefer to wait a couple of days since there is bugfixing going on, each change has to be reflected in the regression matrix, which is only on develop/master and not on the separate branches. To make it clear: I am not in a hurry, not at all. I just like to know a kind of schedule to be able to plan and communicate. Regards, Barend

2015-01-22 12:51 GMT+04:00 John Maddock : <...>

So the interesting question is: why doesn't anyone else seem to need this?

...

I would like this too - bad habit perhaps but I try to minimize merges to release and do "one big release" rather than lots of small ones. It is also useful on multi-person projects (Boost.Math for example) to have a target to aim for.

+1 for having the updated schedule. I need it because of the following: MSVC-14 fails some of the Boost.Variant's variadic template tests. Having the schedule will answer the question: is there a chance that MSVC developers will fix the issues, or shall I disable variadic templates in Boost.Variant for MSVC-14. -- Best regards, Antony Polukhin

[Antony Polukhin]

MSVC-14 fails some of the Boost.Variant's variadic template tests. Having the schedule will answer the question: is there a chance that MSVC developers will fix the issues, or shall I disable variadic templates in Boost.Variant for MSVC-14.

As a favor to Boost, if you send me a *reduced* repro (single source file, no includes beyond CRT to print stuff, less than a page of code), today or tomorrow, I can file it in our internal database and ask the compiler devs to look at it quickly. Time is running out to get fixes into 2015 RTM but it is still possible. STL