Are we on time for the 1.37 release? I notice that the deadline for routine changes passed without any comment (or most of us noticing I suspect). Just checking up on where we are, Cheers, John.
On Tue, Oct 7, 2008 at 1:26 PM, John Maddock <john@johnmaddock.co.uk> wrote:
Are we on time for the 1.37 release?
Hopefully. I've been distracted with other work, so haven't been paying attention, but started picking up the pieces this morning.
I notice that the deadline for routine changes passed without any comment (or most of us noticing I suspect).
Just checking up on where we are,
The only serious problem I'm aware of is that the doc build process is broken again:-( --Beman
Beman Dawes wrote:
On Tue, Oct 7, 2008 at 1:26 PM, John Maddock <john@johnmaddock.co.uk> wrote:
Are we on time for the 1.37 release?
Hopefully. I've been distracted with other work, so haven't been paying attention, but started picking up the pieces this morning.
I notice that the deadline for routine changes passed without any comment (or most of us noticing I suspect).
Just checking up on where we are,
The only serious problem I'm aware of is that the doc build process is broken again:-(
Something in the doc build also prevented me from doing a bjam release two weeks ago :-( So I'll have to try and get a bjam release done ASAP, and merged into the release. But ASAP for me right now means the weekend. So is it OK to do this merge? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
Rene Rivera wrote:
Something in the doc build also prevented me from doing a bjam release two weeks ago :-( So I'll have to try and get a bjam release done ASAP, and merged into the release. But ASAP for me right now means the weekend. So is it OK to do this merge?
I'm not wild about this, actually. It makes me more than a little uncomfortable to think about upgrading the build system this late in the release cycle. Changes to critical infrastructure (like build and test) are best done at the start of the cycle. What exactly would be the impact of this change? -- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric Niebler wrote:
Rene Rivera wrote:
Something in the doc build also prevented me from doing a bjam release two weeks ago :-( So I'll have to try and get a bjam release done ASAP, and merged into the release. But ASAP for me right now means the weekend. So is it OK to do this merge?
I'm not wild about this, actually. It makes me more than a little uncomfortable to think about upgrading the build system this late in the release cycle. Changes to critical infrastructure (like build and test) are best done at the start of the cycle.
FWIW, I'm planning to merge Boost.Build to release as well. Two important changes are: 1. linux->windows crosscompiling support 2. suppression of various configuration messages from libraries that are not built 1 is what folks were running into routinely and 2 is important for larger users of boost. - Volodya
On Thu, Oct 9, 2008 at 12:43 AM, Eric Niebler <eric@boost-consulting.com>wrote:
Rene Rivera wrote:
Something in the doc build also prevented me from doing a bjam release two weeks ago :-( So I'll have to try and get a bjam release done ASAP, and merged into the release. But ASAP for me right now means the weekend. So is it OK to do this merge?
I'm not wild about this, actually. It makes me more than a little uncomfortable to think about upgrading the build system this late in the release cycle.
I share Eric's concern.
Changes to critical infrastructure (like build and test) are best done at the start of the cycle.
Exactly.
What exactly would be the impact of this change?
Also, how quickly can it be done and what are the risks it introduced instabilities? --Beman
Beman Dawes wrote:
On Thu, Oct 9, 2008 at 12:43 AM, Eric Niebler <eric@boost-consulting.com>wrote:
Rene Rivera wrote:
Something in the doc build also prevented me from doing a bjam release two weeks ago :-( So I'll have to try and get a bjam release done ASAP, and merged into the release. But ASAP for me right now means the weekend. So is it OK to do this merge?
I'm not wild about this, actually. It makes me more than a little uncomfortable to think about upgrading the build system this late in the release cycle.
I share Eric's concern.
Changes to critical infrastructure (like build and test) are best done at the start of the cycle.
Exactly.
Aren't trunk tests supposed to show if build and/or test are working fine? - Volodya
Vladimir Prus wrote:
Beman Dawes wrote:
On Thu, Oct 9, 2008 at 12:43 AM, Eric Niebler <eric@boost-consulting.com>wrote:
Rene Rivera wrote:
Something in the doc build also prevented me from doing a bjam release two weeks ago :-( So I'll have to try and get a bjam release done ASAP, and merged into the release. But ASAP for me right now means the weekend. So is it OK to do this merge?
I'm not wild about this, actually. It makes me more than a little uncomfortable to think about upgrading the build system this late in the release cycle.
I share Eric's concern.
Changes to critical infrastructure (like build and test) are best done at the start of the cycle.
Exactly.
Aren't trunk tests supposed to show if build and/or test are working fine?
Testing first on trunk is an important safe-guard against instability on the release branch. But even with that safe-guard in place, instability on release *will* happen at some point -- no system is perfect. And stable build and test tools are so important to our ability to deliver releases on time that holding them to a higher standard is perfectly reasonable, IMO. Let's let Rene explain the nature of the changes and assess the risk. -- Eric Niebler BoostPro Computing http://www.boostpro.com
Vladimir Prus wrote:
Aren't trunk tests supposed to show if build and/or test are working fine?
In my view, the trunk tests are meant to show that the libraries are working fine. As far as I know, there are no tests which are focused on veriftying that the boost tools work fine. Of course, the library tests do test aspects of the tools as sort of a side effect, but it's not an efficient way to test. Robert Ramey
- Volodya
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Robert Ramey wrote:
Vladimir Prus wrote:
Aren't trunk tests supposed to show if build and/or test are working fine?
In my view, the trunk tests are meant to show that the libraries are working fine.
As far as I know, there are no tests which are focused on veriftying that the boost tools work fine.
You mean, "there are no tests that are automatically run together with library tests"?
Of course, the library tests do test aspects of the tools as sort of a side effect, but it's not an efficient way to test.
Whether it's efficient way, and exact definition of efficiency, and why this efficiency is necessary, are good questions, but since we're talking about building C++ Boost libraries and running their tests, if that works on trunk, then it's very likely to work just as well if trunk boost.build is merged to release branch. And it is what matters here. - Volodya
Robert Ramey <ramey <at> rrsd.com> writes:
Vladimir Prus wrote:
Aren't trunk tests supposed to show if build and/or test are working fine?
In my view, the trunk tests are meant to show that the libraries are working fine.
As far as I know, there are no tests which are focused on verifying that the boost tools work fine.
Boost.Test has it's own set of unit tests. Gennadiy
Gennadiy Rozental wrote:
Robert Ramey <ramey <at> rrsd.com> writes:
Vladimir Prus wrote:
Aren't trunk tests supposed to show if build and/or test are working fine?
In my view, the trunk tests are meant to show that the libraries are working fine.
As far as I know, there are no tests which are focused on verifying that the boost tools work fine.
Boost.Test has it's own set of unit tests.
Hmmm - Tastes greate AND less filling. Boost.Test is a boost library AND a boot tool so it gets tested by virtue of its being a library. This is such a good thing that it should be applied to tools as well. What I think would be valuable is a) tools tests be run just as library tests are. b) all tools and libraries be tested against the last current release. The main tools I have in mind are boost.build and the documentation build This would mean that when you made a change to boost test which turned out to break something, it wouldn't ripple to the whole testing process. The same argument would apply to boost build. Library testing and building would rely on the lastest release read versions. Robert Ramey
Gennadiy
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
"BD" == Beman Dawes writes: BD> On Tue, Oct 7, 2008 at 1:26 PM, John Maddock <john@johnmaddock.co.uk> wrote: Are we on time for the 1.37 release?
BD> Hopefully. I've been distracted with other work, so haven't been BD> paying attention, but started picking up the pieces this morning. I had committed several patches to trac, that fixes some of warnings with names shadowing, that are very annoying, especially in boost.spirit, that produces dozens of kilobytes of text for one warning -- With best wishes, Alex Ott, MBA http://alexott.blogspot.com/ http://xtalk.msk.su/~ott/ http://alexott-ru.blogspot.com/
On Thu, Oct 9, 2008 at 2:44 AM, Alex Ott <alexott@gmail.com> wrote:
"BD" == Beman Dawes writes: BD> On Tue, Oct 7, 2008 at 1:26 PM, John Maddock <john@johnmaddock.co.uk> wrote: Are we on time for the 1.37 release?
BD> Hopefully. I've been distracted with other work, so haven't been BD> paying attention, but started picking up the pieces this morning.
I had committed several patches to trac, that fixes some of warnings with names shadowing, that are very annoying, especially in boost.spirit, that produces dozens of kilobytes of text for one warning
Try pestering the developers involved. --Beman
On Tue, Oct 7, 2008 at 4:18 PM, Beman Dawes <bdawes@acm.org> wrote:
On Tue, Oct 7, 2008 at 1:26 PM, John Maddock <john@johnmaddock.co.uk> wrote:
Are we on time for the 1.37 release?
Hopefully. I've been distracted with other work, so haven't been paying attention, but started picking up the pieces this morning.
I notice that the deadline for routine changes passed without any comment (or most of us noticing I suspect).
Just checking up on where we are,
The only serious problem I'm aware of is that the doc build process is broken again:-(
FWIW, the doc build problems have been isolated and a workaround developed. So doc build problems should not delay the release. --Beman
Hi John ! An'n Dienstag 07 Oktober 2008 hett John Maddock schreven:
Are we on time for the 1.37 release? I notice that the deadline for routine changes passed without any comment (or most of us noticing I suspect).
Well, I was caught by surprise, too, Just to be sure: Will or have you merged the latest config changes ? That would be great ;-)) Else I have to patch our in house copy again...
Just checking up on where we are,
That's great. Yours, Jürgen, now trying to prepate some last minute patches... -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold@ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !
Jürgen Hunold wrote:
An'n Dienstag 07 Oktober 2008 hett John Maddock schreven:
Are we on time for the 1.37 release? I notice that the deadline for routine changes passed without any comment (or most of us noticing I suspect).
Well, I was caught by surprise, too, Just to be sure: Will or have you merged the latest config changes ? That would be great ;-)) Else I have to patch our in house copy again...
Not the very very latest changes (just Borland fixes I *think*), but with Beman's permission I will merge them certainly. John.
On Wed, Oct 8, 2008 at 4:46 AM, John Maddock <john@johnmaddock.co.uk> wrote:
Jürgen Hunold wrote:
An'n Dienstag 07 Oktober 2008 hett John Maddock schreven:
Are we on time for the 1.37 release? I notice that the deadline for routine changes passed without any comment (or most of us noticing I suspect).
Well, I was caught by surprise, too, Just to be sure: Will or have you merged the latest config changes ? That would be great ;-)) Else I have to patch our in house copy again...
Not the very very latest changes (just Borland fixes I *think*), but with Beman's permission I will merge them certainly.
Yes, please do. --Beman
Not being a veteran of these things, I'm wondering why it is that 1.37 is following on so soon after 1.36? - Rob.
Robert Jones wrote:
Not being a veteran of these things, I'm wondering why it is that 1.37 is following on so soon after 1.36?
- Rob. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I believe they are targeting quarterly releases. Odd numbers being less stable than even number releases I think is what I understood.
Raindog wrote:
Robert Jones wrote:
Not being a veteran of these things, I'm wondering why it is that 1.37 is following on so soon after 1.36?
- Rob. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I believe they are targeting quarterly releases. Odd numbers being less stable than even number releases I think is what I understood.
There's no difference between odd and even numbered releases for C++ Boost. Odd/even is Linux convention. - Volodya
participants (11)
-
Alex Ott -
Beman Dawes -
Eric Niebler -
Gennadiy Rozental -
John Maddock -
Jürgen Hunold -
Raindog -
Rene Rivera -
Robert Jones -
Robert Ramey -
Vladimir Prus