C++Now! is history, so it is high time to get the 1.50.0 beta out the door. Branches/release is now closed for all changes except by permission from a release manager. Unless there are strong objections, I suggest we close branches\release for all changes next Monday, May 28, and ship the beta release as soon after that as a RC can be built and tested. I'm about to post a separate message discussing the length of beta periods. --Beman
On 22/05/12 13:46, Beman Dawes wrote:
C++Now! is history, so it is high time to get the 1.50.0 beta out the door.
Branches/release is now closed for all changes except by permission from a release manager.
Please can I merge Boost.Thread from trunk to release, along with the scoped enum changes? There are quite a few bug fixes there which I have been meaning to merge once I'd double-checked everything and ensured the tests passed. Cheers, Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++11 thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
On Tue, May 22, 2012 at 8:55 AM, Anthony Williams <anthony.ajw@gmail.com> wrote:
On 22/05/12 13:46, Beman Dawes wrote:
C++Now! is history, so it is high time to get the 1.50.0 beta out the door.
Branches/release is now closed for all changes except by permission from a release manager.
Please can I merge Boost.Thread from trunk to release, along with the scoped enum changes?
Yes, as long as the trunk tests are stable. --Beman
On May 22, 2012, at 6:12 AM, Beman Dawes wrote:
On Tue, May 22, 2012 at 8:55 AM, Anthony Williams <anthony.ajw@gmail.com> wrote:
On 22/05/12 13:46, Beman Dawes wrote:
C++Now! is history, so it is high time to get the 1.50.0 beta out the door.
Branches/release is now closed for all changes except by permission from a release manager.
Please can I merge Boost.Thread from trunk to release, along with the scoped enum changes?
Yes, as long as the trunk tests are stable.
I, too, have some bug fixes for my libraries that I would like to merge to release: Boost.Algorithm (bug fixes and doc fixes) Boost.Array (support for Boost.Hash; tests) -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
C++Now! is history, so it is high time to get the 1.50.0 beta out the
door.
Branches/release is now closed for all changes except by permission from a release manager.
Unless there are strong objections, I suggest we close branches\release for all changes next Monday, May 28, and ship the beta release as soon after that as a RC can be built and tested.
I'm about to post a separate message discussing the length of beta periods.
--Beman
may I add boost.context to 1.50 too? regards, Oliver -- NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a
AMDG On 05/22/2012 06:00 AM, Oliver Kowalke wrote:
C++Now! is history, so it is high time to get the 1.50.0 beta out the
door.
Branches/release is now closed for all changes except by permission from a release manager.
Unless there are strong objections, I suggest we close branches\release for all changes next Monday, May 28, and ship the beta release as soon after that as a RC can be built and tested.
I'm about to post a separate message discussing the length of beta periods.
may I add boost.context to 1.50 too?
By the time we're talking about a beta, it's usually much too late for new libraries. In Christ, Steven Watanabe
I'm about to post a separate message discussing the length of beta periods.
may I add boost.context to 1.50 too?
By the time we're talking about a beta, it's usually much too late for new libraries.
frankly, one thing is talking about a beta, the other thing is announcing the beta schedule with the words `release is now closed' ... this simply gives people no time to plan in advance in order to merge stuff *before* the beta process starts
I'm confused.. How is it that people don't understand that as soon as a release it out the door.. It's then time to merge libraries from trunk to release until the "release branch is closed" announcement goes out. Why is it that people want to wait until right before the release is close to do the merges? On Tue, May 22, 2012 at 10:39 AM, Tim Blechmann <tim@klingt.org> wrote:
I'm about to post a separate message discussing the length of beta periods.
may I add boost.context to 1.50 too?
By the time we're talking about a beta, it's usually much too late for new libraries.
frankly, one thing is talking about a beta, the other thing is announcing the beta schedule with the words `release is now closed' ... this simply gives people no time to plan in advance in order to merge stuff *before* the beta process starts
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
I'm confused.. How is it that people don't understand that as soon as a release it out the door.. It's then time to merge libraries from trunk to release until the "release branch is closed" announcement goes out. Why is it that people want to wait until right before the release is close to do the merges?
Because it's never the right time to merge - there's always "one more little thing" to fix, regression tests being waited on etc etc. If you know when the release branch is going to close *in advance*, then you can plan which fixes are likely to make it, and which won't. On the other hand if there's no sign of the release branch being closed, the temptation to "keep fiddling on trunk" is just too strong. Human nature and all that ;-) So while I understand the reason for the rush, I too would like to see a clear schedule published in advance... Just my 2c yours... John.
On 5/23/2012 12:19 AM, John Maddock wrote:
I'm confused.. How is it that people don't understand that as soon as a release it out the door.. It's then time to merge libraries from trunk to release until the "release branch is closed" announcement goes out. Why is it that people want to wait until right before the release is close to do the merges?
Because it's never the right time to merge - there's always "one more little thing" to fix, regression tests being waited on etc etc. If you know when the release branch is going to close *in advance*, then you can plan which fixes are likely to make it, and which won't. On the other hand if there's no sign of the release branch being closed, the temptation to "keep fiddling on trunk" is just too strong. Human nature and all that ;-)
So while I understand the reason for the rush, I too would like to see a clear schedule published in advance...
Same here. I was surprised by the abrupt closing of trunk. I too have some pending merges to do. I was just waiting for the tests to cycle a bit before doing so. Beman, I also would like to ask for permission to merge Fusion and Spirit. Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com
On 5/22/2012 4:51 PM, Joel de Guzman wrote:
Same here. I was surprised by the abrupt closing of trunk. I too have some pending merges to do. I was just waiting for the tests to cycle a bit before doing so.
Beman, I also would like to ask for permission to merge Fusion and Spirit.
Joel, pls see my message from an hour ago where I reopened the release branch. Feel free to merge as soon as the trunk tests cycle. -- Eric Niebler BoostPro Computing http://www.boostpro.com
I'm confused.. How is it that people don't understand that as soon as a release it out the door.. It's then time to merge libraries from trunk to release until the "release branch is closed" announcement goes out. Why is it that people want to wait until right before the release is close to do the merges?
because people are * busy with other things like day jobs * bugs are reported/fixed at any time * people wait for the tests to cycle before they merge changes into trunk * merging with svn is a pain and people try to limit the number of times they have to mess with it (at least this is my reason) * there is only one `release' branch and not one branch for each release, so it is not very clear what state the branch is in (unless you follow this list every day) fwiw, i'm not a big fan of late merges, either ... in the contrast ... but for the last releases we always had a wonderful schedule which was known in advance. but if you go though the list archives, there were several questions, if there is a release schedule for 1.50. even a question: "Which is the last day to merge to release a big change?" ... maybe you should have written your above advice as answer to that mail? ;)
I'm about to post a separate message discussing the length of beta periods.
may I add boost.context to 1.50 too?
By the time we're talking about a beta, it's usually much too late for new libraries.
frankly, one thing is talking about a beta, the other thing is announcing the beta schedule with the words `release is now closed' ... this simply gives people no time to plan in advance in order to merge stuff *before* the beta process starts
Le 22/05/12 17:52, Rene Rivera a écrit :
I'm confused.. How is it that people don't understand that as soon as a release it out the door.. It's then time to merge libraries from trunk to release until the "release branch is closed" announcement goes out. Why is it that people want to wait until right before the release is close to do the merges?
Hi, I don't think people is waiting until the last moment. They have just things to commit and no calendar has been posted. I recall you that I requested calendar more than 3 weeks ago. Best, Vicente
On 22-5-2012 19:02, Vicente J. Botet Escriba wrote:
Le 22/05/12 17:52, Rene Rivera a écrit :
I'm confused.. How is it that people don't understand that as soon as a release it out the door.. It's then time to merge libraries from trunk to release until the "release branch is closed" announcement goes out. Why is it that people want to wait until right before the release is close to do the merges?
Hi,
I don't think people is waiting until the last moment. They have just things to commit and no calendar has been posted. I recall you that I requested calendar more than 3 weeks ago.
Best, Vicente
I can only confirm this, and the mails of Tim, John, Olaf. There was no news in the calendar at all. And it is still completely empty. I regularly checked the calendar but it was always empty. There were several requests (at least 5) on the mailing list about the schedule. All these mails were never answered with a date (besides that Beman was pinged). So there was no communication, we did not know if there was one week to go, one month, three months... As developers we know to need the schedule in advance, to make plans what to put in, what to finish, what to postpone to next release. Now, the only real communication was the mail of today. We need some period to know in advance of the closure. Next monday is too early, there is only one weekend in between. I suggest a longer period, at least one weekend more (at least, for us). In general I would suggest to know the closure date at least 3 weeks (but preferably much longer, given the fact that we all have a busy live). Thanks, Barend
On 5/22/2012 2:53 PM, Barend Gehrels wrote:
I can only confirm this, and the mails of Tim, John, Olaf. There was no news in the calendar at all. And it is still completely empty. I regularly checked the calendar but it was always empty.
There were several requests (at least 5) on the mailing list about the schedule. All these mails were never answered with a date (besides that Beman was pinged). So there was no communication, we did not know if there was one week to go, one month, three months...
As developers we know to need the schedule in advance, to make plans what to put in, what to finish, what to postpone to next release.
Now, the only real communication was the mail of today.
We need some period to know in advance of the closure. Next monday is too early, there is only one weekend in between. I suggest a longer period, at least one weekend more (at least, for us).
In general I would suggest to know the closure date at least 3 weeks (but preferably much longer, given the fact that we all have a busy live).
The release managers have heard you. We're currently discussing a better plan. I'm personally very sorry for the poor way this has been managed. Look for an email from us shortly. I'm taking it upon myself to reopen the release branch for BUG FIXES ONLY (no new libraries). Please get your changes in as soon as is convenient and prudent. It should be open for at least a week. Then we'll require release manager approval. Please be sure trunk tests are clean before merging anything, as usual. Thanks for your patience. We were all very busy in the run-up to BoostCon, and this got away from us. That's not an excuse, just an explanation. -- Eric Niebler BoostPro Computing http://www.boostpro.com
On Tue, 22 May 2012, Eric Niebler wrote:
On 5/22/2012 2:53 PM, Barend Gehrels wrote:
I can only confirm this, and the mails of Tim, John, Olaf. There was no news in the calendar at all. And it is still completely empty. I regularly checked the calendar but it was always empty.
There were several requests (at least 5) on the mailing list about the schedule. All these mails were never answered with a date (besides that Beman was pinged). So there was no communication, we did not know if there was one week to go, one month, three months...
As developers we know to need the schedule in advance, to make plans what to put in, what to finish, what to postpone to next release.
Now, the only real communication was the mail of today.
We need some period to know in advance of the closure. Next monday is too early, there is only one weekend in between. I suggest a longer period, at least one weekend more (at least, for us).
In general I would suggest to know the closure date at least 3 weeks (but preferably much longer, given the fact that we all have a busy live).
The release managers have heard you. We're currently discussing a better plan. I'm personally very sorry for the poor way this has been managed. Look for an email from us shortly. I'm taking it upon myself to reopen the release branch for BUG FIXES ONLY (no new libraries). Please get your changes in as soon as is convenient and prudent. It should be open for at least a week. Then we'll require release manager approval. Please be sure trunk tests are clean before merging anything, as usual.
Thanks for your patience. We were all very busy in the run-up to BoostCon, and this got away from us. That's not an excuse, just an explanation.
Is this strict "bug fixes only", not allowing new features/changes in existing libraries? -- Jeremiah Willcock
On 5/22/2012 6:12 PM, Jeremiah Willcock wrote:
On Tue, 22 May 2012, Eric Niebler wrote:
The release managers have heard you. We're currently discussing a better plan. I'm personally very sorry for the poor way this has been managed. Look for an email from us shortly. I'm taking it upon myself to reopen the release branch for BUG FIXES ONLY (no new libraries). Please get your changes in as soon as is convenient and prudent. It should be open for at least a week. Then we'll require release manager approval. Please be sure trunk tests are clean before merging anything, as usual.
Thanks for your patience. We were all very busy in the run-up to BoostCon, and this got away from us. That's not an excuse, just an explanation.
Is this strict "bug fixes only", not allowing new features/changes in existing libraries?
Would it be a major inconvenience to hold new features until the next release cycle? That would be my preference, but I'm not speaking for all the release managers. -- Eric Niebler BoostPro Computing http://www.boostpro.com
On Tue, 22 May 2012, Eric Niebler wrote:
On 5/22/2012 6:12 PM, Jeremiah Willcock wrote:
On Tue, 22 May 2012, Eric Niebler wrote:
The release managers have heard you. We're currently discussing a better plan. I'm personally very sorry for the poor way this has been managed. Look for an email from us shortly. I'm taking it upon myself to reopen the release branch for BUG FIXES ONLY (no new libraries). Please get your changes in as soon as is convenient and prudent. It should be open for at least a week. Then we'll require release manager approval. Please be sure trunk tests are clean before merging anything, as usual.
Thanks for your patience. We were all very busy in the run-up to BoostCon, and this got away from us. That's not an excuse, just an explanation.
Is this strict "bug fixes only", not allowing new features/changes in existing libraries?
Would it be a major inconvenience to hold new features until the next release cycle? That would be my preference, but I'm not speaking for all the release managers.
No, it wouldn't -- I can wait, but would prefer to merge my changes/refactorings in now so that the trunk and release branch will not differ by too much. -- Jeremiah Willcock
On Tue, May 22, 2012 at 9:18 PM, Jeremiah Willcock <jewillco@osl.iu.edu> wrote:
On Tue, 22 May 2012, Eric Niebler wrote:
Would it be a major inconvenience to hold new features until the next release cycle? That would be my preference, but I'm not speaking for all the release managers.
No, it wouldn't -- I can wait, but would prefer to merge my changes/refactorings in now so that the trunk and release branch will not differ by too much.
It is an issue of risk. How long have these changes/refactorings been stable in trunk? How extensive were the changes? Were the changes fragile or once they worked on your development platform, did they pass all tests on other platforms? Have you done a local merge to release, and tested the results? --Beman
On Wed, 23 May 2012, Beman Dawes wrote:
On Tue, May 22, 2012 at 9:18 PM, Jeremiah Willcock <jewillco@osl.iu.edu> wrote:
On Tue, 22 May 2012, Eric Niebler wrote:
Would it be a major inconvenience to hold new features until the next release cycle? That would be my preference, but I'm not speaking for all the release managers.
No, it wouldn't -- I can wait, but would prefer to merge my changes/refactorings in now so that the trunk and release branch will not differ by too much.
It is an issue of risk. How long have these changes/refactorings been stable in trunk? How extensive were the changes? Were the changes fragile or once they worked on your development platform, did they pass all tests on other platforms? Have you done a local merge to release, and tested the results?
The main change is that I refactored the handling of properties stored inside graphs, so it is somewhat extensive. It did seem to work on the full list of platforms relatively quickly. I have not tried to do a merge locally yet, but I'd do that before I committed any changes. -- Jeremiah Willcock
On Wed, May 23, 2012 at 4:12 PM, Jeremiah Willcock <jewillco@osl.iu.edu> wrote:
On Wed, 23 May 2012, Beman Dawes wrote:
On Tue, May 22, 2012 at 9:18 PM, Jeremiah Willcock <jewillco@osl.iu.edu> wrote:
On Tue, 22 May 2012, Eric Niebler wrote:
Would it be a major inconvenience to hold new features until the next release cycle? That would be my preference, but I'm not speaking for all the release managers.
No, it wouldn't -- I can wait, but would prefer to merge my changes/refactorings in now so that the trunk and release branch will not differ by too much.
It is an issue of risk. How long have these changes/refactorings been stable in trunk? How extensive were the changes? Were the changes fragile or once they worked on your development platform, did they pass all tests on other platforms? Have you done a local merge to release, and tested the results?
The main change is that I refactored the handling of properties stored inside graphs, so it is somewhat extensive. It did seem to work on the full list of platforms relatively quickly. I have not tried to do a merge locally yet, but I'd do that before I committed any changes.
Do the merge locally, and test on any compilers you have access to. If that's OK, commit the merge, but revert if any regression tests fail unexpectedly and the fixes aren't trivial or can't be applied right away. --Beman --Beman
On Wed, 23 May 2012, Beman Dawes wrote:
On Wed, May 23, 2012 at 4:12 PM, Jeremiah Willcock <jewillco@osl.iu.edu> wrote:
On Wed, 23 May 2012, Beman Dawes wrote:
On Tue, May 22, 2012 at 9:18 PM, Jeremiah Willcock <jewillco@osl.iu.edu> wrote:
On Tue, 22 May 2012, Eric Niebler wrote:
Would it be a major inconvenience to hold new features until the next release cycle? That would be my preference, but I'm not speaking for all the release managers.
No, it wouldn't -- I can wait, but would prefer to merge my changes/refactorings in now so that the trunk and release branch will not differ by too much.
It is an issue of risk. How long have these changes/refactorings been stable in trunk? How extensive were the changes? Were the changes fragile or once they worked on your development platform, did they pass all tests on other platforms? Have you done a local merge to release, and tested the results?
The main change is that I refactored the handling of properties stored inside graphs, so it is somewhat extensive. It did seem to work on the full list of platforms relatively quickly. I have not tried to do a merge locally yet, but I'd do that before I committed any changes.
Do the merge locally, and test on any compilers you have access to. If that's OK, commit the merge, but revert if any regression tests fail unexpectedly and the fixes aren't trivial or can't be applied right away.
I tried to do the merge, then realized that some of my changes depend on TypeTraits Introspection which apparently hasn't been merged yet. Because of that and trouble I had getting other things to work after the merge, I'll wait until 1.51. -- Jeremiah Willcock
On 5/23/2012 3:00 PM, Jeremiah Willcock wrote:
I tried to do the merge, then realized that some of my changes depend on TypeTraits Introspection which apparently hasn't been merged yet. Because of that and trouble I had getting other things to work after the merge, I'll wait until 1.51.
Thanks, Jeremiah. -- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric Niebler-3 wrote
On 5/22/2012 6:12 PM, Jeremiah Willcock wrote:
On Tue, 22 May 2012, Eric Niebler wrote:
The release managers have heard you. We're currently discussing a better plan. I'm personally very sorry for the poor way this has been managed. Look for an email from us shortly. I'm taking it upon myself to reopen the release branch for BUG FIXES ONLY (no new libraries). Please get your changes in as soon as is convenient and prudent. It should be open for at least a week. Then we'll require release manager approval. Please be sure trunk tests are clean before merging anything, as usual.
Thanks for your patience. We were all very busy in the run-up to BoostCon, and this got away from us. That's not an excuse, just an explanation.
Is this strict "bug fixes only", not allowing new features/changes in existing libraries?
Would it be a major inconvenience to hold new features until the next release cycle? That would be my preference, but I'm not speaking for all the release managers.
It would be for ScopeExit, LocalFunction, OverloadedFunction, and IdentityType because these libraries have been ready for a while (regression tested on all compilers, reviewed by managers and other library authors, etc). I didn't merge them into release simply because I was think I still had time and I had been busy at work in the last 2 weeks (I and Vicente asked for a 1.50 release date a few times more than 3 weeks ago but got no answer, not the release was closed the same day it was announced). I put a lot of effort into getting these libraries ready, they are ready, not to include them in 1.50 because of a miss-communication invalidates a large part of the effort I put into developing and testing this libraries... Thank you for your understand. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/1-50-0-Beta-schedule-tp4630328p4630392.ht... Sent from the Boost - Dev mailing list archive at Nabble.com.
On Wed, May 23, 2012 at 3:25 AM, lcaminiti <lorcaminiti@gmail.com> wrote:
It would be for ScopeExit, LocalFunction, OverloadedFunction, and IdentityType because these libraries have been ready for a while (regression tested on all compilers, reviewed by managers and other library authors, etc). I didn't merge them into release simply because I was think I still had time and I had been busy at work in the last 2 weeks (I and Vicente asked for a 1.50 release date a few times more than 3 weeks ago but got no answer, not the release was closed the same day it was announced). I put a lot of effort into getting these libraries ready, they are ready, not to include them in 1.50 because of a miss-communication invalidates a large part of the effort I put into developing and testing this libraries...
Isn't that exaggerated? They could go into 1.51. -- Olaf
Olaf van der Spek-3 wrote
On Wed, May 23, 2012 at 3:25 AM, lcaminiti <lorcaminiti@> wrote:
It would be for ScopeExit, LocalFunction, OverloadedFunction, and IdentityType because these libraries have been ready for a while (regression tested on all compilers, reviewed by managers and other library authors, etc). I didn't merge them into release simply because I was think I still had time and I had been busy at work in the last 2 weeks (I and Vicente asked for a 1.50 release date a few times more than 3 weeks ago but got no answer, not the release was closed the same day it was announced). I put a lot of effort into getting these libraries ready, they are ready, not to include them in 1.50 because of a miss-communication invalidates a large part of the effort I put into developing and testing this libraries...
Isn't that exaggerated? They could go into 1.51.
My point is that a truly put a lot of effort to meet the 1.50 target and that is slipping away for miss-communication, which is rather unfortunate. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/1-50-0-Beta-schedule-tp4630328p4630404.ht... Sent from the Boost - Dev mailing list archive at Nabble.com.
On Wed, May 23, 2012 at 1:54 PM, lcaminiti <lorcaminiti@gmail.com> wrote:
Olaf van der Spek-3 wrote
On Wed, May 23, 2012 at 3:25 AM, lcaminiti <lorcaminiti@> wrote:
It would be for ScopeExit, LocalFunction, OverloadedFunction, and IdentityType because these libraries have been ready for a while (regression tested on all compilers, reviewed by managers and other library authors, etc). I didn't merge them into release simply because I was think I still had time and I had been busy at work in the last 2 weeks (I and Vicente asked for a 1.50 release date a few times more than 3 weeks ago but got no answer, not the release was closed the same day it was announced). I put a lot of effort into getting these libraries ready, they are ready, not to include them in 1.50 because of a miss-communication invalidates a large part of the effort I put into developing and testing this libraries...
Isn't that exaggerated? They could go into 1.51.
My point is that a truly put a lot of effort to meet the 1.50 target and that is slipping away for miss-communication, which is rather unfortunate.
Yes, the communication is bad. But the target for major merges is the begin of the release cycle, not the end. -- Olaf
On 23 May 2012 12:56, Olaf van der Spek <ml@vdspek.org> wrote:
On Wed, May 23, 2012 at 1:54 PM, lcaminiti <lorcaminiti@gmail.com> wrote:
My point is that a truly put a lot of effort to meet the 1.50 target and that is slipping away for miss-communication, which is rather unfortunate.
Yes, the communication is bad. But the target for major merges is the begin of the release cycle, not the end.
To be fair to Lorenzo, he requested that we (the release managers) look at his libraries some time ago, and I don't think he was warned that they needed to be merged. I haven't checked up on them since, but IIRC some of the libraries were ready, some needed a little more work (and I think he understood what needed to be done). I possibly should have instructed him to merge things that are ready sooner rather than later, although I thought that went without saying. I'll take another look at his changes later (or maybe someone else will?), and consult the other release managers (this isn't really my thing).
On 5/23/2012 5:11 AM, Daniel James wrote:
On 23 May 2012 12:56, Olaf van der Spek <ml@vdspek.org> wrote:
On Wed, May 23, 2012 at 1:54 PM, lcaminiti <lorcaminiti@gmail.com> wrote:
My point is that a truly put a lot of effort to meet the 1.50 target and that is slipping away for miss-communication, which is rather unfortunate.
Yes, the communication is bad. But the target for major merges is the begin of the release cycle, not the end.
To be fair to Lorenzo, he requested that we (the release managers) look at his libraries some time ago, and I don't think he was warned that they needed to be merged. I haven't checked up on them since, but IIRC some of the libraries were ready, some needed a little more work (and I think he understood what needed to be done). I possibly should have instructed him to merge things that are ready sooner rather than later, although I thought that went without saying.
I'll take another look at his changes later (or maybe someone else will?), and consult the other release managers (this isn't really my thing).
I'm not familiar with the state of these libraries, but I'm sympathetic to Lorenzo. Assuming everything looks ok, this release manager would be ok with allowing Lorenzo's new stuff into 1.49. -- Eric Niebler BoostPro Computing http://www.boostpro.com
Olaf van der Spek-3 wrote
On Wed, May 23, 2012 at 1:54 PM, lcaminiti <lorcaminiti@> wrote:
Olaf van der Spek-3 wrote
On Wed, May 23, 2012 at 3:25 AM, lcaminiti <lorcaminiti@> wrote:
It would be for ScopeExit, LocalFunction, OverloadedFunction, and IdentityType because these libraries have been ready for a while (regression tested on all compilers, reviewed by managers and other library authors, etc). I didn't merge them into release simply because I was think I still had time and I had been busy at work in the last 2 weeks (I and Vicente asked for a 1.50 release date a few times more than 3 weeks ago but got no answer, not the release was closed the same day it was announced). I put a lot of effort into getting these libraries ready, they are ready, not to include them in 1.50 because of a miss-communication invalidates a large part of the effort I put into developing and testing this libraries...
Isn't that exaggerated? They could go into 1.51.
My point is that a truly put a lot of effort to meet the 1.50 target and that is slipping away for miss-communication, which is rather unfortunate.
Yes, the communication is bad. But the target for major merges is the begin of the release cycle, not the end.
It's OK, I guess. While I read all the guidelines on the Boost site, I'm just left with learning the process the hard way :) If when Vicente and I asked for a release date 3+ weeks ago someone had said "don't know when we'll close release but your new libs should be merged ASAP because you already passed the begin of the release cycle time", that would have at least hinted the current situation and I'd have taken appropriate actions... Getting no reply instead, gave me no clue. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/1-50-0-Beta-schedule-tp4630328p4630410.ht... Sent from the Boost - Dev mailing list archive at Nabble.com.
I'm taking it upon myself to reopen the release branch for BUG FIXES ONLY (no new libraries).
What are the reasons not to allow new libraries? Oliver -- NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a
On Wed, May 23, 2012 at 07:38:52AM +0200, Oliver Kowalke wrote:
I'm taking it upon myself to reopen the release branch for BUG FIXES ONLY (no new libraries).
What are the reasons not to allow new libraries?
The way it kind of once worked was that you merge libraries pretty much directly after the previous release, then twiddle your thumbs until the beta and release dates. The way it tends to work in reality is that everyone panics their work in at the last moment possible, or slightly later. In the end, it's a massive misunderstanding between authors that played it safe and assumed that the lack of any announced dates meant that release merging was in some way delayed, and the release managers which run on a fixed internal unannounced clock, assuming that everyone knew their thoughts. -- Lars Viklund | zao@acc.umu.se
On Wed, May 23, 2012 at 6:16 AM, Lars Viklund <zao@acc.umu.se> wrote:
On Wed, May 23, 2012 at 07:38:52AM +0200, Oliver Kowalke wrote:
I'm taking it upon myself to reopen the release branch for BUG FIXES ONLY (no new libraries).
What are the reasons not to allow new libraries?
The way it kind of once worked was that you merge libraries pretty much directly after the previous release, then twiddle your thumbs until the beta and release dates.
The way it tends to work in reality is that everyone panics their work in at the last moment possible, or slightly later.
In the end, it's a massive misunderstanding between authors that played it safe and assumed that the lack of any announced dates meant that release merging was in some way delayed, and the release managers which run on a fixed internal unannounced clock, assuming that everyone knew their thoughts.
See https://svn.boost.org/trac/boost/wiki/ReleaseSchedule --Beman
On 22 May 2012 23:46, Eric Niebler <eric@boostpro.com> wrote:
Look for an email from us shortly. I'm taking it upon myself to reopen the release branch for BUG FIXES ONLY (no new libraries). Please get your changes in as soon as is convenient and prudent. It should be open for at least a week. Then we'll require release manager approval. Please be sure trunk tests are clean before merging anything, as usual.
I added a 'release branch closed' event to the calendar for next Monday, which is a little less than a week, but we normally do these things on Mondays. This is in no way final (I just picked a date), and might be changed later.
Daniel James-3 wrote
On 22 May 2012 23:46, Eric Niebler <eric@> wrote:
Look for an email from us shortly. I'm taking it upon myself to reopen the release branch for BUG FIXES ONLY (no new libraries). Please get your changes in as soon as is convenient and prudent. It should be open for at least a week. Then we'll require release manager approval. Please be sure trunk tests are clean before merging anything, as usual.
I added a 'release branch closed' event to the calendar for next Monday, which is a little less than a week, but we normally do these things on Mondays. This is in no way final (I just picked a date), and might be changed later.
To confirm, does this mean that release is open for merging, including new features, until next Monday? Thanks. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/1-50-0-Beta-schedule-tp4630328p4630405.ht... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 23 May 2012 12:55, lcaminiti <lorcaminiti@gmail.com> wrote:
Daniel James-3 wrote
On 22 May 2012 23:46, Eric Niebler <eric@> wrote:
Look for an email from us shortly. I'm taking it upon myself to reopen the release branch for BUG FIXES ONLY (no new libraries). Please get your changes in as soon as is convenient and prudent. It should be open for at least a week. Then we'll require release manager approval. Please be sure trunk tests are clean before merging anything, as usual.
I added a 'release branch closed' event to the calendar for next Monday, which is a little less than a week, but we normally do these things on Mondays. This is in no way final (I just picked a date), and might be changed later.
To confirm, does this mean that release is open for merging, including new features, until next Monday?
No. It just means I added an arbitrary date to the calendar.
On Wed, May 23, 2012 at 7:55 AM, lcaminiti <lorcaminiti@gmail.com> wrote:
Daniel James-3 wrote
On 22 May 2012 23:46, Eric Niebler <eric@> wrote:
Look for an email from us shortly. I'm taking it upon myself to reopen the release branch for BUG FIXES ONLY (no new libraries). Please get your changes in as soon as is convenient and prudent. It should be open for at least a week. Then we'll require release manager approval. Please be sure trunk tests are clean before merging anything, as usual.
I added a 'release branch closed' event to the calendar for next Monday, which is a little less than a week, but we normally do these things on Mondays. This is in no way final (I just picked a date), and might be changed later.
To confirm, does this mean that release is open for merging, including new features, until next Monday?
"BUG FIXES ONLY" does not include new features. You can ask for permission to merge a new feature. If it has been stable in trunk for awhile and is otherwise low risk, then we may OK a merge. But we are playing catch up for a release that was supposed to be done at the beginning of the month, so are trying to avoid anything that will result in further delays. --Beman
Beman Dawes wrote
On Wed, May 23, 2012 at 7:55 AM, lcaminiti <lorcaminiti@> wrote:
Daniel James-3 wrote
On 22 May 2012 23:46, Eric Niebler <eric@> wrote:
Look for an email from us shortly. I'm taking it upon myself to reopen the release branch for BUG FIXES ONLY (no new libraries). Please get your changes in as soon as is convenient and prudent. It should be open for at least a week. Then we'll require release manager approval. Please be sure trunk tests are clean before merging anything, as usual.
I added a 'release branch closed' event to the calendar for next Monday, which is a little less than a week, but we normally do these things on Mondays. This is in no way final (I just picked a date), and might be changed later.
To confirm, does this mean that release is open for merging, including new features, until next Monday?
"BUG FIXES ONLY" does not include new features.
You can ask for permission to merge a new feature. If it has been stable in trunk for awhile and is otherwise low risk, then we may OK a merge. But we are playing catch up for a release that was supposed to be done at the beginning of the month, so are trying to avoid anything that will result in further delays.
Do I have permission to merge ScopeExit (improved), LocalFunction (new), Funcitonal/OverloadedFunction (new), and Utility/IdentityType (new)? If so, I can do that within today. I'm answering your questions below from another email to assess the risk.
It is an issue of risk. How long have these changes/refactorings been stable in trunk? 1+ month.
How extensive were the changes? ScopeExit ("small" library) 20% new but all old regressions plus all new regressions pass. LocalFunction ("small/mid-size" library), OverloadedFunction ("small" library), and IdentityType ("tiny" library) 100% new.
Were the changes fragile or once they worked on your development platform, did they pass all tests on other platforms? Regressions passed on all compilers with little efforts after they passed on MSVC and GCC on my development platform. Sun, and a little bit VACPP plus PGI, were the only compilers that required some amount of extra work. All of this was done 1+ month ago in trunk. That applies to all ScopeExit, LocalFunction, OverloadedFunciton, and IdentityType.
Have you done a local merge to release, and tested the results? Yes. I tested on MSVC 8.0, GCC 4.5.3 without and without C++11 feature (that's my development platform). The tests pass on my development platform for release as they do for trunk.
Please advice. Thank you very much. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/1-50-0-Beta-schedule-tp4630328p4630417.ht... Sent from the Boost - Dev mailing list archive at Nabble.com.
I would just like to put a vote for Boost.Context to be included. On May 23, 2012, at 9:45 AM, lcaminiti wrote:
Beman Dawes wrote
On Wed, May 23, 2012 at 7:55 AM, lcaminiti <lorcaminiti@> wrote:
Daniel James-3 wrote
On 22 May 2012 23:46, Eric Niebler <eric@> wrote:
Look for an email from us shortly. I'm taking it upon myself to reopen the release branch for BUG FIXES ONLY (no new libraries). Please get your changes in as soon as is convenient and prudent. It should be open for at least a week. Then we'll require release manager approval. Please be sure trunk tests are clean before merging anything, as usual.
I added a 'release branch closed' event to the calendar for next Monday, which is a little less than a week, but we normally do these things on Mondays. This is in no way final (I just picked a date), and might be changed later.
To confirm, does this mean that release is open for merging, including new features, until next Monday?
"BUG FIXES ONLY" does not include new features.
You can ask for permission to merge a new feature. If it has been stable in trunk for awhile and is otherwise low risk, then we may OK a merge. But we are playing catch up for a release that was supposed to be done at the beginning of the month, so are trying to avoid anything that will result in further delays.
Do I have permission to merge ScopeExit (improved), LocalFunction (new), Funcitonal/OverloadedFunction (new), and Utility/IdentityType (new)? If so, I can do that within today.
I'm answering your questions below from another email to assess the risk.
It is an issue of risk. How long have these changes/refactorings been stable in trunk? 1+ month.
How extensive were the changes? ScopeExit ("small" library) 20% new but all old regressions plus all new regressions pass. LocalFunction ("small/mid-size" library), OverloadedFunction ("small" library), and IdentityType ("tiny" library) 100% new.
Were the changes fragile or once they worked on your development platform, did they pass all tests on other platforms? Regressions passed on all compilers with little efforts after they passed on MSVC and GCC on my development platform. Sun, and a little bit VACPP plus PGI, were the only compilers that required some amount of extra work. All of this was done 1+ month ago in trunk. That applies to all ScopeExit, LocalFunction, OverloadedFunciton, and IdentityType.
Have you done a local merge to release, and tested the results? Yes. I tested on MSVC 8.0, GCC 4.5.3 without and without C++11 feature (that's my development platform). The tests pass on my development platform for release as they do for trunk.
Please advice.
Thank you very much. --Lorenzo
-- View this message in context: http://boost.2283326.n4.nabble.com/1-50-0-Beta-schedule-tp4630328p4630417.ht... Sent from the Boost - Dev mailing list archive at Nabble.com.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Wed, May 23, 2012 at 9:45 AM, lcaminiti <lorcaminiti@gmail.com> wrote:
Beman Dawes wrote
On Wed, May 23, 2012 at 7:55 AM, lcaminiti <lorcaminiti@> wrote:
Daniel James-3 wrote
On 22 May 2012 23:46, Eric Niebler <eric@> wrote:
Look for an email from us shortly. I'm taking it upon myself to reopen the release branch for BUG FIXES ONLY (no new libraries). Please get your changes in as soon as is convenient and prudent. It should be open for at least a week. Then we'll require release manager approval. Please be sure trunk tests are clean before merging anything, as usual.
I added a 'release branch closed' event to the calendar for next Monday, which is a little less than a week, but we normally do these things on Mondays. This is in no way final (I just picked a date), and might be changed later.
To confirm, does this mean that release is open for merging, including new features, until next Monday?
"BUG FIXES ONLY" does not include new features.
You can ask for permission to merge a new feature. If it has been stable in trunk for awhile and is otherwise low risk, then we may OK a merge. But we are playing catch up for a release that was supposed to be done at the beginning of the month, so are trying to avoid anything that will result in further delays.
Do I have permission to merge ScopeExit (improved), LocalFunction (new), Funcitonal/OverloadedFunction (new), and Utility/IdentityType (new)? If so, I can do that within today.
I'm answering your questions below from another email to assess the risk.
It is an issue of risk. How long have these changes/refactorings been stable in trunk? 1+ month.
How extensive were the changes? ScopeExit ("small" library) 20% new but all old regressions plus all new regressions pass. LocalFunction ("small/mid-size" library), OverloadedFunction ("small" library), and IdentityType ("tiny" library) 100% new.
Were the changes fragile or once they worked on your development platform, did they pass all tests on other platforms? Regressions passed on all compilers with little efforts after they passed on MSVC and GCC on my development platform. Sun, and a little bit VACPP plus PGI, were the only compilers that required some amount of extra work. All of this was done 1+ month ago in trunk. That applies to all ScopeExit, LocalFunction, OverloadedFunciton, and IdentityType.
Have you done a local merge to release, and tested the results? Yes. I tested on MSVC 8.0, GCC 4.5.3 without and without C++11 feature (that's my development platform). The tests pass on my development platform for release as they do for trunk.
Please advice.
That sounds OK to me; you have the risks pretty well covered. Several other release managers are also in favor of a go ahead, so please merge to release ASAP and keep a close eye on the release regression tests. Thanks, --Beman
Beman Dawes wrote
On Wed, May 23, 2012 at 9:45 AM, lcaminiti <lorcaminiti@> wrote:
Beman Dawes wrote
On Wed, May 23, 2012 at 7:55 AM, lcaminiti <lorcaminiti@> wrote:
Daniel James-3 wrote
On 22 May 2012 23:46, Eric Niebler <eric@> wrote:
Look for an email from us shortly. I'm taking it upon myself to reopen the release branch for BUG FIXES ONLY (no new libraries). Please get your changes in as soon as is convenient and prudent. It should be open for at least a week. Then we'll require release manager approval. Please be sure trunk tests are clean before merging anything, as usual.
I added a 'release branch closed' event to the calendar for next Monday, which is a little less than a week, but we normally do these things on Mondays. This is in no way final (I just picked a date), and might be changed later.
To confirm, does this mean that release is open for merging, including new features, until next Monday?
"BUG FIXES ONLY" does not include new features.
You can ask for permission to merge a new feature. If it has been stable in trunk for awhile and is otherwise low risk, then we may OK a merge. But we are playing catch up for a release that was supposed to be done at the beginning of the month, so are trying to avoid anything that will result in further delays.
Do I have permission to merge ScopeExit (improved), LocalFunction (new), Funcitonal/OverloadedFunction (new), and Utility/IdentityType (new)? If so, I can do that within today.
I'm answering your questions below from another email to assess the risk.
It is an issue of risk. How long have these changes/refactorings been stable in trunk? 1+ month.
How extensive were the changes? ScopeExit ("small" library) 20% new but all old regressions plus all new regressions pass. LocalFunction ("small/mid-size" library), OverloadedFunction ("small" library), and IdentityType ("tiny" library) 100% new.
Were the changes fragile or once they worked on your development platform, did they pass all tests on other platforms? Regressions passed on all compilers with little efforts after they passed on MSVC and GCC on my development platform. Sun, and a little bit VACPP plus PGI, were the only compilers that required some amount of extra work. All of this was done 1+ month ago in trunk. That applies to all ScopeExit, LocalFunction, OverloadedFunciton, and IdentityType.
Have you done a local merge to release, and tested the results? Yes. I tested on MSVC 8.0, GCC 4.5.3 without and without C++11 feature (that's my development platform). The tests pass on my development platform for release as they do for trunk.
Please advice.
That sounds OK to me; you have the risks pretty well covered. Several other release managers are also in favor of a go ahead, so please merge to release ASAP and keep a close eye on the release regression tests.
Will do. I'll merge by tonight. Thanks. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/1-50-0-Beta-schedule-tp4630328p4630443.ht... Sent from the Boost - Dev mailing list archive at Nabble.com.
lcaminiti wrote
Beman Dawes wrote
On Wed, May 23, 2012 at 9:45 AM, lcaminiti <lorcaminiti@> wrote:
Beman Dawes wrote
On Wed, May 23, 2012 at 7:55 AM, lcaminiti <lorcaminiti@> wrote:
Daniel James-3 wrote
On 22 May 2012 23:46, Eric Niebler <eric@> wrote: > > Look for an email from us shortly. I'm taking it upon myself to > reopen > the release branch for BUG FIXES ONLY (no new libraries). Please get > your changes in as soon as is convenient and prudent. It should be > open > for at least a week. Then we'll require release manager approval. > Please > be sure trunk tests are clean before merging anything, as usual.
I added a 'release branch closed' event to the calendar for next Monday, which is a little less than a week, but we normally do these things on Mondays. This is in no way final (I just picked a date), and might be changed later.
To confirm, does this mean that release is open for merging, including new features, until next Monday?
"BUG FIXES ONLY" does not include new features.
You can ask for permission to merge a new feature. If it has been stable in trunk for awhile and is otherwise low risk, then we may OK a merge. But we are playing catch up for a release that was supposed to be done at the beginning of the month, so are trying to avoid anything that will result in further delays.
Do I have permission to merge ScopeExit (improved), LocalFunction (new), Funcitonal/OverloadedFunction (new), and Utility/IdentityType (new)? If so, I can do that within today.
I'm answering your questions below from another email to assess the risk.
It is an issue of risk. How long have these changes/refactorings been stable in trunk? 1+ month.
How extensive were the changes? ScopeExit ("small" library) 20% new but all old regressions plus all new regressions pass. LocalFunction ("small/mid-size" library), OverloadedFunction ("small" library), and IdentityType ("tiny" library) 100% new.
Were the changes fragile or once they worked on your development platform, did they pass all tests on other platforms? Regressions passed on all compilers with little efforts after they passed on MSVC and GCC on my development platform. Sun, and a little bit VACPP plus PGI, were the only compilers that required some amount of extra work. All of this was done 1+ month ago in trunk. That applies to all ScopeExit, LocalFunction, OverloadedFunciton, and IdentityType.
Have you done a local merge to release, and tested the results? Yes. I tested on MSVC 8.0, GCC 4.5.3 without and without C++11 feature (that's my development platform). The tests pass on my development platform for release as they do for trunk.
Please advice.
That sounds OK to me; you have the risks pretty well covered. Several other release managers are also in favor of a go ahead, so please merge to release ASAP and keep a close eye on the release regression tests.
Will do. I'll merge by tonight.
Done. I will be watching the release regression tests very closely for the next few days. Thanks a lot. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/1-50-0-Beta-schedule-tp4630328p4630450.ht... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 23-5-2012 0:46, Eric Niebler wrote:
I can only confirm this, and the mails of Tim, John, Olaf. There was no news in the calendar at all. And it is still completely empty. I regularly checked the calendar but it was always empty.
There were several requests (at least 5) on the mailing list about the schedule. All these mails were never answered with a date (besides that Beman was pinged). So there was no communication, we did not know if there was one week to go, one month, three months...
As developers we know to need the schedule in advance, to make plans what to put in, what to finish, what to postpone to next release.
Now, the only real communication was the mail of today.
We need some period to know in advance of the closure. Next monday is too early, there is only one weekend in between. I suggest a longer period, at least one weekend more (at least, for us).
In general I would suggest to know the closure date at least 3 weeks (but preferably much longer, given the fact that we all have a busy live). The release managers have heard you. We're currently discussing a better
On 5/22/2012 2:53 PM, Barend Gehrels wrote: plan. I'm personally very sorry for the poor way this has been managed. Look for an email from us shortly. I'm taking it upon myself to reopen the release branch for BUG FIXES ONLY (no new libraries). Please get your changes in as soon as is convenient and prudent. It should be open for at least a week. Then we'll require release manager approval. Please be sure trunk tests are clean before merging anything, as usual.
Thanks for your patience. We were all very busy in the run-up to BoostCon, and this got away from us. That's not an excuse, just an explanation.
Eric, thanks a lot for your quick answer and follow up! Regards, Barend
On Tue, May 22, 2012 at 9:00 AM, Oliver Kowalke <oliver.kowalke@gmx.de> wrote:
may I add boost.context to 1.50 too?
It is way past the point we usually add new libraries. And you have some tab cleanup to do: boost\context\detail\fcontext_arm.hpp: *Tab* boost\context\detail\fcontext_i386.hpp: *Tab* boost\context\detail\fcontext_i386_win.hpp: *Tab* boost\context\detail\fcontext_mips.hpp: *Tab* boost\context\detail\fcontext_ppc.hpp: *Tab* boost\context\detail\fcontext_x86_64.hpp: *Tab* boost\context\detail\fcontext_x86_64_win.hpp: *Tab* libs\context\example\exit.cpp: *Tab* libs\context\example\jump.cpp: *Tab* libs\context\example\transfer.cpp: *Tab* libs\context\performance\performance.cpp: *Tab* libs\context\src\fcontext.cpp: *Tab* libs\context\src\stack_allocator_posix.cpp: *Tab* libs\context\test\test_context.cpp: *Tab* Has the Review Manager taken a look at trunk to verify issues identified during the formal review? --Beman
Am 22.05.2012 21:40, schrieb Beman Dawes:
On Tue, May 22, 2012 at 9:00 AM, Oliver Kowalke<oliver.kowalke@gmx.de> wrote:
may I add boost.context to 1.50 too? It is way past the point we usually add new libraries.
Hmm - I was waiting for an announcement for the merge window for the next release and I didn't found an related entry in the boost calendar. I did not found an info on boost website which branch has to be used for merging (I'm guessing it is branch 'release' in http://svn.boost.org/svn/boost/branches). Maybe this is 'implicit' knowledge.
And you have some tab cleanup to do:
boost\context\detail\fcontext_arm.hpp: *Tab* boost\context\detail\fcontext_i386.hpp: *Tab* boost\context\detail\fcontext_i386_win.hpp: *Tab* boost\context\detail\fcontext_mips.hpp: *Tab* boost\context\detail\fcontext_ppc.hpp: *Tab* boost\context\detail\fcontext_x86_64.hpp: *Tab* boost\context\detail\fcontext_x86_64_win.hpp: *Tab* libs\context\example\exit.cpp: *Tab* libs\context\example\jump.cpp: *Tab* libs\context\example\transfer.cpp: *Tab* libs\context\performance\performance.cpp: *Tab* libs\context\src\fcontext.cpp: *Tab* libs\context\src\stack_allocator_posix.cpp: *Tab* libs\context\test\test_context.cpp: *Tab*
done in trunk
Has the Review Manager taken a look at trunk to verify issues identified during the formal review?
only some issued related to the documentation which I think is fixed. So - does it mean I've no luck to submit the lib? Oliver
AMDG On 05/22/2012 12:40 PM, Beman Dawes wrote:
On Tue, May 22, 2012 at 9:00 AM, Oliver Kowalke <oliver.kowalke@gmx.de> wrote:
may I add boost.context to 1.50 too?
It is way past the point we usually add new libraries.
And you have some tab cleanup to do:
<snip>
Has the Review Manager taken a look at trunk to verify issues identified during the formal review?
It looks like Oliver went ahead before anyone replied.
Author: olli Date: 2012-05-22 11:16:49 EDT (Tue, 22 May 2012) New Revision: 78539 URL: http://svn.boost.org/trac/boost/changeset/78539
Log: context: added to release
In Christ, Steven Watanabe
Am 22.05.2012 22:24, schrieb Steven Watanabe:
On Tue, May 22, 2012 at 9:00 AM, Oliver Kowalke<oliver.kowalke@gmx.de> wrote:
may I add boost.context to 1.50 too? It is way past the point we usually add new libraries.
And you have some tab cleanup to do:
<snip>
Has the Review Manager taken a look at trunk to verify issues identified during the formal review?
It looks like Oliver went ahead before anyone replied.
mini-review issued only some hints related to the documentation - I thought it would be OK.
Author: olli Date: 2012-05-22 11:16:49 EDT (Tue, 22 May 2012) New Revision: 78539 URL: http://svn.boost.org/trac/boost/changeset/78539
Log: context: added to release
I already ask Beman to remove it from 'release' :( Oliver
C++Now! is history, so it is high time to get the 1.50.0 beta out the door.
mhm ... i was quite surprised to see that no dates for 1.50 have been posted to the calendar, so i didn't know what state the release branch is in (well, haven't asked or searched the archive, either) ... iac, i would have appreciated if a date would have been posted, when the release branch is closed.
Branches/release is now closed for all changes except by permission from a release manager.
requesting permission to merge some small fixes for boost.heap, that are in trunk. if i had known the schedule for 1.50 like two weeks ago, i would have added boost.lockfree with the restriction of being c++11 only, as at least recent versions of clang++ and g++ provide a sufficient implementation of c++11 atomic<> (i start having the feeling that boost.atomic is going to be obsolete once it will be added) ... but iac, boost.lockfree will have to wait for 1.51 tim
On Tue, May 22, 2012 at 2:46 PM, Beman Dawes <bdawes@acm.org> wrote:
C++Now! is history, so it is high time to get the 1.50.0 beta out the door.
Branches/release is now closed for all changes except by permission from a release manager.
Hi Beman, What's the reason no schedule was posted? Now the branch gets closed without advance notice. Olaf
On Tue, May 22, 2012 at 5:46 AM, Beman Dawes <bdawes@acm.org> wrote:
C++Now! is history, so it is high time to get the 1.50.0 beta out the door.
Branches/release is now closed for all changes except by permission from a release manager.
Request to merge https://svn.boost.org/trac/boost/changeset/78501 which just takes care of a shadowing warning on gcc. Couple things: (a) I just went ahead and made this change on trunk a few days ago because I stumbled into this warning myself, searched track, and saw that it was already reported and had a patch (indirectly) attached; in retrospect, I apologize if I stepped on anyone's (Jeremy's?) toes, and so I ask: Is there a formal or informal protocol for applying relatively simple patches like this one? (b) Along the same lines, assuming permission is granted and given (a), should I be merging this to release, or should that fall to the library maintainer? Thanks, - Jeff
Beman Dawes wrote
C++Now! is history, so it is high time to get the 1.50.0 beta out the door.
Branches/release is now closed for all changes except by permission from a release manager.
Unless there are strong objections, I suggest we close branches\release for all changes next Monday, May 28, and ship the beta release as soon after that as a RC can be built and tested.
I'm about to post a separate message discussing the length of beta periods.
I'm sorry I missed this... Do I have time to merge Boost.ScopeExit, LocalFunction, IdentityType and OverloadedFunction over this weekend? These changes have been stable in the trunk for a while and I just need to do a svn merge for them. Thank you. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/1-50-0-Beta-schedule-tp4630328p4630387.ht... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 5/22/2012 5:42 PM, lcaminiti wrote:
Beman Dawes wrote
C++Now! is history, so it is high time to get the 1.50.0 beta out the door.
Branches/release is now closed for all changes except by permission from a release manager.
Unless there are strong objections, I suggest we close branches\release for all changes next Monday, May 28, and ship the beta release as soon after that as a RC can be built and tested.
I'm about to post a separate message discussing the length of beta periods.
I'm sorry I missed this... Do I have time to merge Boost.ScopeExit, LocalFunction, IdentityType and OverloadedFunction over this weekend? These changes have been stable in the trunk for a while and I just need to do a svn merge for them.
Could you characterize the changes? Are they new libraries (then no), new features to existing libraries (hold these until the release managers have discussed the issue further), or just bug fixes (then go ahead)? -- Eric Niebler BoostPro Computing http://www.boostpro.com
participants (19)
-
Anthony Williams -
Barend Gehrels -
Beman Dawes -
Daniel James -
Daniel Larimer -
Eric Niebler -
Jeffrey Lee Hellrung, Jr. -
Jeremiah Willcock -
Joel de Guzman -
John Maddock -
Lars Viklund -
lcaminiti -
Marshall Clow -
Olaf van der Spek -
Oliver Kowalke -
Rene Rivera -
Steven Watanabe -
Tim Blechmann -
Vicente J. Botet Escriba