Hi, I will not accept any changes to 1.34.0 whatsoever starting Thursday May 3. Please make sure you report all problems/fixes/doc changes till then. Only real show stoppers (i.e. build might start thermonuclear war) will be considered after that date. That notwithstanding please DO NOT SUBMIT to RC_1_34_0 without prior approval. Thanks Thomas
--- Thomas Witt wrote:
Hi,
I will not accept any changes to 1.34.0 whatsoever starting Thursday May 3. Please make sure you report all problems/fixes/doc changes till then.
A few somewhat-recently accepted libraries (e.g. ASIO, Fusion, Interprocess, MPI, PropertyTree) are available in both the beta distribution and via CVS but are not advertised in either libs/libraries.htm or doc/html/index.html; will their presence at least be announced in the news section of the home page during the official release? Cromwell D. Enage __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
In article <624789.81580.qm@web53912.mail.re2.yahoo.com> Cromwell Enage <sponage@yahoo.com> wrote:
A few somewhat-recently accepted libraries (e.g. ASIO, Fusion, Interprocess, MPI, PropertyTree) are available in both the beta distribution and via CVS but are not advertised in either libs/libraries.htm or doc/html/index.html; will their presence at least be announced in the news section of the home page during the official release?
As of now there is no such plan. They are not part of the official release and as such are not mentioned in the docs. Thomas
Thomas Witt wrote:
In article <624789.81580.qm@web53912.mail.re2.yahoo.com> Cromwell Enage <sponage@yahoo.com> wrote:
A few somewhat-recently accepted libraries (e.g. ASIO, Fusion, Interprocess, MPI, PropertyTree) are available in both the beta distribution and via CVS but are not advertised in either libs/libraries.htm or doc/html/index.html; will their presence at least be announced in the news section of the home page during the official release?
As of now there is no such plan. They are not part of the official release and as such are not mentioned in the docs.
To clarify, none of the listed libraries are in the beta distribution I have. And property tree isn't in CVS yet AFAICS. Most of these libraries should be in 1.35, which will hopefully be released 'quickly'. By quickly, I mean ~1.5 months...which means a beta release 1 month after 1.34. Yep, that's right, I think we need to set some very hard goals to re-energize the boost release process. After the '1.34 experience' I've become even more of an advocate a hard line release approach. That is, we should set the deadline and only accept code that can make it in the release timeframe -- if it's not ready then we take it out and let it slide to the next release. To minimize risk of delay and release the pent-up backlog of new libraries I believe we should hold all existing 1.34 libs constant and only add in new libraries that are basically ready to go now. I've actually done an 'alpha test' of this approach and it looks like this will work -- that is, most of the unreleased libraries can be build against a 1.34 core without dependencies on changes to existing libraries (there are a few minor exceptions). Behind the scenes I've been encouraging developers of new libs to get their code into CVS so we will be ready to begin the nano-second after 1.34 ships. Now, I realize that we have a plan to switch to subversion and have a new process that has been developed by Beman, etc. But it's my view that we should pursue a CVS based approach because it requires zero time to implement. In the meantime the subversion conversion can proceed in parallel. When everything is 100% ready to go we switch. My worry is that the conversion of regression testing, developers, and all other release process changes will wind up delaying 1.35 by several months. Of course, if my pessimism is misplaced then we can switch to subversion for the 1.35 release. Nothing will have been lost because we will have been testing new libs for 1.35 anyway. I believe this is urgent because a major backlog of unreleased Boost code has now developed. The asio review was 1.5 years ago -- it's hard to fathom that it's not in a release yet. It's simply not acceptable to wait even 3 months more to get asio and other 'new' libs into a boost release. And besides, asio and the libs above are really just the short list: there's xpressive, GIL, bimap, accumulators, function types, and units that have been accepted now -- huge and important libraries. And it's not stopping, there's a review backlog, a pile of SoC projects, etc. We have to dramatically shorten the release cycle to get these libraries out into a release. Jeff
Jeff Garland wrote: [...]
Most of these libraries should be in 1.35, which will hopefully be released 'quickly'. By quickly, I mean ~1.5 months...which means a beta release 1 month after 1.34. Yep, that's right, I think we need to set some very hard goals to re-energize the boost release process. After the '1.34 experience' I've become even more of an advocate a hard line release approach. That is, we should set the deadline and only accept code that can make it in the release timeframe -- if it's not ready then we take it out and let it slide to the next release.
I wholeheartedly agree! On the other hand for this to happen it is necessary to stop addition of new libraries now. Are there any approved libraries that aren't in CVS yet? If there are maybe they should be allowed a time slot for new additions, before going into a bug fix only mode.
To minimize risk of delay and release the pent-up backlog of new libraries I believe we should hold all existing 1.34 libs constant and only add in new libraries that are basically ready to go now. I've actually done an 'alpha test' of this approach and it looks like this will work -- that is, most of the unreleased libraries can be build against a 1.34 core without dependencies on changes to existing libraries (there are a few minor exceptions). Behind the scenes I've been encouraging developers of new libs to get their code into CVS so we will be ready to begin the nano-second after 1.34 ships.
Are you implying that you'd set aside all changes to existing libraries that are already in HEAD? Isn't this a bit tough on library authors that put in up to a year and a half to improve their libraries?
Now, I realize that we have a plan to switch to subversion and have a new process that has been developed by Beman, etc. But it's my view that we should pursue a CVS based approach because it requires zero time to implement. In the meantime the subversion conversion can proceed in parallel. When everything is 100% ready to go we switch. My worry is that the conversion of regression testing, developers, and all other release process changes will wind up delaying 1.35 by several months. Of course, if my pessimism is misplaced then we can switch to subversion for the 1.35 release. Nothing will have been lost because we will have been testing new libs for 1.35 anyway.
Are there tools to keep Subversion and CVS repositories synchronized? If that's the case the adaptation of the infrastructure to Subversion could take place in a development branch while your plan is carried out.
I believe this is urgent because a major backlog of unreleased Boost code has now developed. The asio review was 1.5 years ago -- it's hard to fathom that it's not in a release yet. It's simply not acceptable to wait even 3 months more to get asio and other 'new' libs into a boost release. And besides, asio and the libs above are really just the short list: there's xpressive, GIL, bimap, accumulators, function types, and units that have been accepted now -- huge and important libraries. And it's not stopping, there's a review backlog, a pile of SoC projects, etc. We have to dramatically shorten the release cycle to get these libraries out into a release.
I believe there are to sides to this: one is to come out with 1.35 as fast as possible to make up for lost time, the other is to ensure that such delays do not happen again. In this respect I'm afraid that Beman's approach shares with the current one too much reliance on self discipline and team cohesion. Boost is too large and too intertwined to rely so much on self discipline and team cohesion simply is not there, apart possibly among a small number of veteran core developers. Witness for instance how many were taken by surprise by the switch to BBv2. Cheers, Nicola Musatti
Nicola Musatti wrote:
Jeff Garland wrote: [...]
Most of these libraries should be in 1.35, which will hopefully be released 'quickly'. By quickly, I mean ~1.5 months...which means a beta release 1 month after 1.34. Yep, that's right, I think we need to set some very hard goals to re-energize the boost release process. After the '1.34 experience' I've become even more of an advocate a hard line release approach. That is, we should set the deadline and only accept code that can make it in the release timeframe -- if it's not ready then we take it out and let it slide to the next release.
I wholeheartedly agree! On the other hand for this to happen it is necessary to stop addition of new libraries now. Are there any approved libraries that aren't in CVS yet? If there are maybe they should be allowed a time slot for new additions, before going into a bug fix only mode.
property tree, bimap, accumulators at least. But yes, we would need to specify a cutoff for addition to make the schedule. However, with more frequent releases it's not as big a deal if something slips.
To minimize risk of delay and release the pent-up backlog of new libraries I believe we should hold all existing 1.34 libs constant and only add in new libraries that are basically ready to go now. I've actually done an 'alpha test' of this approach and it looks like this will work -- that is, most of the unreleased libraries can be build against a 1.34 core without dependencies on changes to existing libraries (there are a few minor exceptions). Behind the scenes I've been encouraging developers of new libs to get their code into CVS so we will be ready to begin the nano-second after 1.34 ships.
Are you implying that you'd set aside all changes to existing libraries that are already in HEAD? Isn't this a bit tough on library authors that put in up to a year and a half to improve their libraries?
Yep, but I suspect many of the really critical fixes got moved into 1.34. If there's someone with a really important exception it could be discussed, but it would have to be really good.
Now, I realize that we have a plan to switch to subversion and have a new process that has been developed by Beman, etc. But it's my view that we should pursue a CVS based approach because it requires zero time to implement. In the meantime the subversion conversion can proceed in parallel. When everything is 100% ready to go we switch. My worry is that the conversion of regression testing, developers, and all other release process changes will wind up delaying 1.35 by several months. Of course, if my pessimism is misplaced then we can switch to subversion for the 1.35 release. Nothing will have been lost because we will have been testing new libs for 1.35 anyway.
Are there tools to keep Subversion and CVS repositories synchronized? If that's the case the adaptation of the infrastructure to Subversion could take place in a development branch while your plan is carried out.
Don't know, but I'm sure the infrastructure development can be done in parallel with just a little thought.
I believe this is urgent because a major backlog of unreleased Boost code has now developed. The asio review was 1.5 years ago -- it's hard to fathom that it's not in a release yet. It's simply not acceptable to wait even 3 months more to get asio and other 'new' libs into a boost release. And besides, asio and the libs above are really just the short list: there's xpressive, GIL, bimap, accumulators, function types, and units that have been accepted now -- huge and important libraries. And it's not stopping, there's a review backlog, a pile of SoC projects, etc. We have to dramatically shorten the release cycle to get these libraries out into a release.
I believe there are to sides to this: one is to come out with 1.35 as fast as possible to make up for lost time, the other is to ensure that such delays do not happen again. In this respect I'm afraid that Beman's approach shares with the current one too much reliance on self discipline and team cohesion.
Actually, I think Beman's new approach is much closer in philosophy to what I'm suggesting. As I recall in provides for a small window to fix regressions after which breaking changes will be reverted. It's ultimate goal is to keep the HEAD much closer to release at all times. Still, it is untested so we don't know how it will really work yet.
Boost is too large and too intertwined to rely so much on self discipline and team cohesion simply is not there, apart possibly among a small number of veteran core developers.
Actually I think the main thing is that Boost is getting large enough now that there's almost always something being changed.
Witness for instance how many were taken by surprise by the switch to BBv2.
I don't want to dwell on BBv2, but after doing several similar conversions on large projects I was afraid it would be much harder than expected -- it's extremely hard to even make a list of all the things to do let alone what will go wrong. And when something goes wrong progress bogs down. I fear the same thing with subversion conversion. On it's face it should be easy, but there's alot of people, tools, and small non-obvious dependencies on CVS. I haven't even seen a list of all the scripts, web pages, processes, etc that need to changed before the changeover can be completed-- so I'm afraid we don't fully understand the impacts. Jeff
Jeff Garland wrote:
Are there tools to keep Subversion and CVS repositories synchronized? If that's the case the adaptation of the infrastructure to Subversion could take place in a development branch while your plan is carried out.
Don't know, but I'm sure the infrastructure development can be done in parallel with just a little thought.
I would expect that the switch to subversion itself takes only little time, and requires only little adjustment to existing infrastructure bits (automated checkouts and updates, checkin notifications, etc.). What takes a bit longer is the preparation of the move (but that can be done while a new release is still prepared from CVS), as well as some subsequent cleanup (directory reorganization, etc.) following the move. So, I don't see any need to keep two repositories in parallel, really. I'd be curious to know how easy a switch from CVS to SVN with the current boost repository would be. Douglas, have you attempted to run cvs2svn or similar on the repository ? How much work is needed before the transfer could happen ? Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...
On May 1, 2007, at 10:23 AM, Stefan Seefeld wrote:
Jeff Garland wrote:
Are there tools to keep Subversion and CVS repositories synchronized? If that's the case the adaptation of the infrastructure to Subversion could take place in a development branch while your plan is carried out.
Don't know, but I'm sure the infrastructure development can be done in parallel with just a little thought.
I would expect that the switch to subversion itself takes only little time, and requires only little adjustment to existing infrastructure bits (automated checkouts and updates, checkin notifications, etc.). What takes a bit longer is the preparation of the move (but that can be done while a new release is still prepared from CVS), as well as some subsequent cleanup (directory reorganization, etc.) following the move.
We've been preparing for more than a month, and we've done it before.
So, I don't see any need to keep two repositories in parallel, really.
It's a pain to keep two repositories in parallel. I, personally, will not volunteer to do that work.
I'd be curious to know how easy a switch from CVS to SVN with the current boost repository would be. Douglas, have you attempted to run cvs2svn or similar on the repository ?
Yes, of course. We've converted several repositories before, including Boost. Up until yesterday, we had a full Boost SVN+Sandbox SVN+Trac running on the OSL servers for testing purposes... now, we're preparing to move the sandbox. I'll send an announcement for the sandbox switchover "soon".
How much work is needed before the transfer could happen ?
Most of the work is done. When we're ready to switch (and *after* 1.34.0 is out the door), we'll ask for a 24-hour window to make sure we have enough time for the cvs2svn conversion and import (roughly 8 hours of crunching), and to deal with any issues that might crop up. - Doug
Doug Gregor wrote:
Most of the work is done. When we're ready to switch (and *after* 1.34.0 is out the door), we'll ask for a 24-hour window to make sure we have enough time for the cvs2svn conversion and import (roughly 8 hours of crunching), and to deal with any issues that might crop up.
That's excellent news ! So it seems holding the switch off for another release isn't even on the table. I guess if everything can be straightened out within a matter of days there won't be any need to keep the old CVS repository around, either. Then the next step is to configure a way to give all the current developers having write-permission write access again (ssh / accounts on the new servers ?) Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Stefan Seefeld wrote:
Doug Gregor wrote:
Most of the work is done. When we're ready to switch (and *after* 1.34.0 is out the door), we'll ask for a 24-hour window to make sure we have enough time for the cvs2svn conversion and import (roughly 8 hours of crunching), and to deal with any issues that might crop up.
That's excellent news ! So it seems holding the switch off for another release isn't even on the table. I guess if everything can be straightened out within a matter of days there won't be any need to keep the old CVS repository around, either.
Sorry, it's not going to happen that fast....see my reply to Doug. We're going to need volunteers to update regression scripts, run tests, and write procedures. We shouldn't try to switch all the regression testers in a big bang -- we need to get a few volunteers to work with whoever modifies the scripts and to help work out issues. Jeff
Jeff Garland wrote:
Stefan Seefeld wrote:
Doug Gregor wrote:
Most of the work is done. When we're ready to switch (and *after* 1.34.0 is out the door), we'll ask for a 24-hour window to make sure we have enough time for the cvs2svn conversion and import (roughly 8 hours of crunching), and to deal with any issues that might crop up. That's excellent news ! So it seems holding the switch off for another release isn't even on the table. I guess if everything can be straightened out within a matter of days there won't be any need to keep the old CVS repository around, either.
Sorry, it's not going to happen that fast....see my reply to Doug. We're going to need volunteers to update regression scripts, run tests, and write procedures. We shouldn't try to switch all the regression testers in a big bang -- we need to get a few volunteers to work with whoever modifies the scripts and to help work out issues.
But, independent on how many people need to change their habit, the only thing they actually need to change is a single command: s/cvs co .... /svn co ...../ (with appropriate URLs). I agree that docs for that part of the 'procedure' may be spread over lots of places, and that they all need fixing. But let's not stare at the problem like a deer into the light of an approaching car. (And yes, if there is a list of items to be fixed, I'd happily volunteer.) Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Stefan Seefeld wrote:
But, independent on how many people need to change their habit, the only
That will take time by itself...
thing they actually need to change is a single command: s/cvs co .... /svn co ...../ (with appropriate URLs).
I agree that docs for that part of the 'procedure' may be spread over lots of places, and that they all need fixing. But let's not stare at the problem like a deer into the light of an approaching car.
As soon as I see regression runners using an official script against an OSL svn I'll be happy to shut up.
(And yes, if there is a list of items to be fixed, I'd happily volunteer.)
Ah, the first job is to make a list of them -- they're all on boost.org -- please do so. The ones I know of off hand: http://www.boost.org/more/release_procedures.htm http://www.boost.org/tools/regression/xsl_reports/runner/instructions.html http://www.boost.org/more/getting_started.html http://www.boost.org/more/release_mgr_checklist.html Probably a more general way is to do this query: http://www.google.com/search?num=20&hl=en&safe=off&client=firefox&rls=org.mozilla%3Aen-US%3Aunofficial&hs=RYu&q=cvs+site%3Awww.boost.org&btnG=Search Oh and since we won't have sourceforge CVS instructions any longer we'll need something like this page as well: http://sourceforge.net/cvs/?group_id=7586 Jeff
Jeff Garland wrote:
Stefan Seefeld wrote:
But, independent on how many people need to change their habit, the only
That will take time by itself...
Right. But the clock will only start ticking once the switch is done.
(And yes, if there is a list of items to be fixed, I'd happily volunteer.)
Ah, the first job is to make a list of them -- they're all on boost.org -- please do so. The ones I know of off hand:
http://www.boost.org/more/release_procedures.htm http://www.boost.org/tools/regression/xsl_reports/runner/instructions.html http://www.boost.org/more/getting_started.html http://www.boost.org/more/release_mgr_checklist.html
Probably a more general way is to do this query:
How are these fixed ? What's the equivalent location in the repository ? (We are not going to update the live website to point to not-yet-true information, right ?)
Oh and since we won't have sourceforge CVS instructions any longer we'll need something like this page as well:
Obviously. But that's pretty trivial, too. Thanks for the list ! Doug, do you have a set of URLs for the repository that will be correct after the switch ? Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Stefan Seefeld wrote:
Jeff Garland wrote:
Stefan Seefeld wrote:
But, independent on how many people need to change their habit, the only That will take time by itself...
Right. But the clock will only start ticking once the switch is done.
(And yes, if there is a list of items to be fixed, I'd happily volunteer.) Ah, the first job is to make a list of them -- they're all on boost.org -- please do so. The ones I know of off hand:
http://www.boost.org/more/release_procedures.htm http://www.boost.org/tools/regression/xsl_reports/runner/instructions.html http://www.boost.org/more/getting_started.html http://www.boost.org/more/release_mgr_checklist.html
Probably a more general way is to do this query:
How are these fixed ? What's the equivalent location in the repository ? (We are not going to update the live website to point to not-yet-true information, right ?)
Some clarification is in order... After 1.34.0, and before 1.35.0, the website will not be integral to the release sources. This has some immediate effects for thinking about the svn switch: * People can start migrating non-release documentation to the new website immediately. This includes some of the above docs. * The website content doesn't need to be complete before making it public. * As soon as the new website is public, we are free to do a release without worrying about when the website is updated. With that in mind perhaps it's a good idea to switch the new website content over to svn ASAP so that I can make some structural changes, and so that people can start moving over website documentation. Doug, what do you think... Could you make the website module move available soon? -- -- 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
on Tue May 01 2007, Stefan Seefeld <seefeld-AT-sympatico.ca> wrote:
Jeff Garland wrote:
Sorry, it's not going to happen that fast....see my reply to Doug. We're going to need volunteers to update regression scripts, run tests, and write procedures. We shouldn't try to switch all the regression testers in a big bang -- we need to get a few volunteers to work with whoever modifies the scripts and to help work out issues.
But, independent on how many people need to change their habit, the only thing they actually need to change is a single command: s/cvs co .... /svn co ...../ (with appropriate URLs).
I agree. Jeff, you're really blowing that part of the switch out of proportion. I agree we need to consider the costs, but let's do so realistically. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
On May 1, 2007, at 11:35 AM, Stefan Seefeld wrote:
Doug Gregor wrote:
Most of the work is done. When we're ready to switch (and *after* 1.34.0 is out the door), we'll ask for a 24-hour window to make sure we have enough time for the cvs2svn conversion and import (roughly 8 hours of crunching), and to deal with any issues that might crop up.
That's excellent news ! So it seems holding the switch off for another release isn't even on the table. I guess if everything can be straightened out within a matter of days there won't be any need to keep the old CVS repository around, either.
Then the next step is to configure a way to give all the current developers having write-permission write access again (ssh / accounts on the new servers ?)
We can't migrate the user data from SourceForge directly, so we'll be sending out invitations from our Subversion management software. In some ways, it's a good thing: it allows us to prune the list of developers down to active developers, gives us a chance to implement a more fine-grained security policy (since the sandbox will now be part of the same repository), etc. Actually, Stefan, you'll be getting one of those invitations in a few minutes, just in case you'd like to help us move some of the CVS- specific documentation over to the Trac... - Doug
on Tue May 01 2007, Stefan Seefeld <seefeld-AT-sympatico.ca> wrote:
Then the next step is to configure a way to give all the current developers having write-permission write access again
We're actually planning to do that by request only, to weed out inactive developers.
(ssh / accounts on the new servers ?)
Fortunately you don't need that with SVN. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
Doug Gregor wrote:
How much work is needed before the transfer could happen ?
Most of the work is done. When we're ready to switch (and *after* 1.34.0 is out the door), we'll ask for a 24-hour window to make sure we have enough time for the cvs2svn conversion and import (roughly 8 hours of crunching), and to deal with any issues that might crop up.
Doug, while I agree that most of the work for switching the repository itself is on track, I don't believe any of the "other work" has been done. Specifically, I mean the regression scripts and procedure writeups. It's my view that if we can't make the switch until these tasks are complete. And I suspect we really need some volunteers to make this happen... Jeff
Jeff Garland wrote:
Doug Gregor wrote:
How much work is needed before the transfer could happen ? Most of the work is done. When we're ready to switch (and *after* 1.34.0 is out the door), we'll ask for a 24-hour window to make sure we have enough time for the cvs2svn conversion and import (roughly 8 hours of crunching), and to deal with any issues that might crop up.
Doug, while I agree that most of the work for switching the repository itself is on track, I don't believe any of the "other work" has been done. Specifically, I mean the regression scripts and procedure writeups. It's my view that if we can't make the switch until these tasks are complete. And I suspect we really need some volunteers to make this happen...
Now I'm starting to get confused. Before you said that you didn't expect that library authors would have to do much for the switch. And now you are saying it's not a small amount of work. Whom other than lib authors is going to update the documentation, test scripts, build scripts, whatever? Personally I think it's foolish to rely on a small number of people to do the switch work. And the only way I know of, from experience, to ensure we get authors to help is to force them do the work. Sorry if that sounds harsh, but it's true. -- -- 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
Rene Rivera wrote:
Jeff Garland wrote:
Doug Gregor wrote:
How much work is needed before the transfer could happen ? Most of the work is done. When we're ready to switch (and *after* 1.34.0 is out the door), we'll ask for a 24-hour window to make sure we have enough time for the cvs2svn conversion and import (roughly 8 hours of crunching), and to deal with any issues that might crop up. Doug, while I agree that most of the work for switching the repository itself is on track, I don't believe any of the "other work" has been done. Specifically, I mean the regression scripts and procedure writeups. It's my view that if we can't make the switch until these tasks are complete. And I suspect we really need some volunteers to make this happen...
Now I'm starting to get confused. Before you said that you didn't expect that library authors would have to do much for the switch. And now you
Maybe I shouldn't have said 'won't' ;-)
are saying it's not a small amount of work. Whom other than lib authors is going to update the documentation, test scripts, build scripts, whatever?
I honestly don't know how much work it is because I've never seen a full accounting of the needed changes, but it will take some time. All developers, will, of course, have to do some learning about svn, but most of us have already started down this path so I don't think that will take alot of time. As for build/regression stuff it might be 'a library author' that updates the regression script, but really, most of us are totally unqualified to do that work. We need to recruit new blood to get things like the docs updated...
Personally I think it's foolish to rely on a small number of people to do the switch work.
I agree, the more help the better. But we also shouldn't force the new library authors to shoulder that load of updating the regression script. We should let them focus on getting their libs ported and ready for release in my view.
And the only way I know of, from experience, to ensure we get authors to help is to force them do the work. Sorry if that sounds harsh, but it's true.
There's no forcing here...only gentle encouragement. Jeff
on Tue May 01 2007, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
Jeff Garland wrote:
Doug Gregor wrote:
How much work is needed before the transfer could happen ? Most of the work is done. When we're ready to switch (and *after* 1.34.0 is out the door), we'll ask for a 24-hour window to make sure we have enough time for the cvs2svn conversion and import (roughly 8 hours of crunching), and to deal with any issues that might crop up.
Doug, while I agree that most of the work for switching the repository itself is on track, I don't believe any of the "other work" has been done. Specifically, I mean the regression scripts and procedure writeups. It's my view that if we can't make the switch until these tasks are complete. And I suspect we really need some volunteers to make this happen...
Now I'm starting to get confused. Before you said that you didn't expect that library authors would have to do much for the switch. And now you are saying it's not a small amount of work. Whom other than lib authors is going to update the documentation, test scripts, build scripts, whatever? Personally I think it's foolish to rely on a small number of people to do the switch work. And the only way I know of, from experience, to ensure we get authors to help is to force them do the work. Sorry if that sounds harsh, but it's true.
There just isn't all that much work AFAICT. I'd be willing to update all the scripts, though I'd prefer if someone else would volunteer just because I'm overloaded. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
On May 1, 2007, at 11:40 AM, Jeff Garland wrote:
Doug Gregor wrote:
How much work is needed before the transfer could happen ?
Most of the work is done. When we're ready to switch (and *after* 1.34.0 is out the door), we'll ask for a 24-hour window to make sure we have enough time for the cvs2svn conversion and import (roughly 8 hours of crunching), and to deal with any issues that might crop up.
Doug, while I agree that most of the work for switching the repository itself is on track, I don't believe any of the "other work" has been done. Specifically, I mean the regression scripts and procedure writeups. It's my view that if we can't make the switch until these tasks are complete. And I suspect we really need some volunteers to make this happen...
Information about accessing the Subversion repository is here: http://svn.boost.org/trac/boost/wiki/BoostSubversion It's on our Trac, which has its own wiki. Any developer with access to the Subversion repository can add/modify/delete pages on the Trac. I very strongly encourage us to migrate developer-centric information over to the Trac, because it's so much easier to modify than the web site. For volunteers to help us migrate CVS-centric documentation to SVN-centric documentation, they need only get a Subversion account (see the above page), then start editing the Trac wiki. As for the regression scripts... I don't expect that it will be a huge change, although it will take some time to ripple through. I run several sets of tests at OSL, so of course these will be the first to move over to the Subversion repository. - Doug
Jeff Garland wrote:
Actually, I think Beman's new approach is much closer in philosophy to what I'm suggesting. As I recall in provides for a small window to fix regressions after which breaking changes will be reverted. It's ultimate goal is to keep the HEAD much closer to release at all times. Still, it is untested so we don't know how it will really work yet.
As I understand it, "keep HEAD release-ready" is the opposite of what you are suggesting, which is "branch 1.35 as soon as 1.34 is released". In fact, there is no need to wait for 1.34 to be released - you can have the 1.35 branch proceeding in parallel (general lack of resources aside.)
Peter Dimov wrote:
Jeff Garland wrote:
Actually, I think Beman's new approach is much closer in philosophy to what I'm suggesting. As I recall in provides for a small window to fix regressions after which breaking changes will be reverted. It's ultimate goal is to keep the HEAD much closer to release at all times. Still, it is untested so we don't know how it will really work yet.
As I understand it, "keep HEAD release-ready" is the opposite of what you are suggesting, which is "branch 1.35 as soon as 1.34 is released". In fact, there is no need to wait for 1.34 to be released - you can have the 1.35 branch proceeding in parallel (general lack of resources aside.)
Agree, and actually I have been trying to move things forward with what little time I have. I've been rabble rousing behind the scenes to get authors to get their libs checked into CVS. We have a couple libs: asio and xpressive whose regressions are already clean on several of the release compilers. We need to get the other new libs into the regression test suite so we can assess their state. Eric and Chris can start working on markup/changes for the other regressions, etc, etc. The bottleneck I see is the regression testers. Right now Thomas needs them to keep running against 1.34 for final patches he's adding in. Going forward, I believe we will need significant time and energy from the regression runners as we test the subversion switchover. What I'd like to see happen is that instead of going back to main branch after Thomas is done we swap the regression testers over to the 1.35 branch immediately. The folks testing main can be the first beta-testers for subversion switchover. Jeff
Jeff Garland wrote:
The bottleneck I see is the regression testers. Right now Thomas needs them to keep running against 1.34 for final patches he's adding in. Going forward, I believe we will need significant time and energy from the regression runners as we test the subversion switchover. What I'd like to see happen is that instead of going back to main branch after Thomas is done we swap the regression testers over to the 1.35 branch immediately. The folks testing main can be the first beta-testers for subversion switchover.
The problem with this scheme - from a library developer point of view - is that one cannot experiment with new features since nobody is testing HEAD. One possible outcome is then for 1.35 to become a de-facto HEAD and absorb most of the new development.
Peter Dimov wrote:
Jeff Garland wrote:
The bottleneck I see is the regression testers. Right now Thomas needs them to keep running against 1.34 for final patches he's adding in. Going forward, I believe we will need significant time and energy from the regression runners as we test the subversion switchover. What I'd like to see happen is that instead of going back to main branch after Thomas is done we swap the regression testers over to the 1.35 branch immediately. The folks testing main can be the first beta-testers for subversion switchover.
The problem with this scheme - from a library developer point of view - is that one cannot experiment with new features since nobody is testing HEAD. One possible outcome is then for 1.35 to become a de-facto HEAD and absorb most of the new development.
It wouldn't be for long b/c the end date of the release would be fixed :-) And maybe now is the time to try and find a few more regression runners so we can do more branches at once. BTW, I don't know if this has been discussed much, but the plan for subversion switchover, as I understand it, is to take 1.34 as the svn HEAD and force all work unstable stuff on the CVS HEAD to be brought over using the new process. Jeff
Jeff Garland wrote:
BTW, I don't know if this has been discussed much, but the plan for subversion switchover, as I understand it, is to take 1.34 as the svn HEAD and force all work unstable stuff on the CVS HEAD to be brought over using the new process.
That would be very impolite. :-)
on Tue May 01 2007, "Peter Dimov" <pdimov-AT-mmltd.net> wrote:
Jeff Garland wrote:
BTW, I don't know if this has been discussed much, but the plan for subversion switchover, as I understand it, is to take 1.34 as the svn HEAD and force all work unstable stuff on the CVS HEAD to be brought over using the new process.
That would be very impolite. :-)
I'm not sure this transition *can* be a "polite" process if it's going to work. That said, I'm open to suggestions. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
David Abrahams <dave <at> boost-consulting.com> writes:
on Tue May 01 2007, "Peter Dimov" <pdimov-AT-mmltd.net> wrote:
Jeff Garland wrote:
BTW, I don't know if this has been discussed much, but the plan for subversion switchover, as I understand it, is to take 1.34 as the svn HEAD and force all work unstable stuff on the CVS HEAD to be brought over using the new process.
That would be very impolite.
I'm not sure this transition *can* be a "polite" process if it's going to work. That said, I'm open to suggestions.
Maybe it's just a misunderstanding. Am I right in assuming that the idea is to make 1.34 the svn stable branch and the current CVS HEAD the svn development branch? After all the only other way to move towards Beman's process would be to allow bug fixes only on HEAD until it becomes stable, whenever that may happen. Suddenly the first alternative becomes way more attractive :-) Cheers, Nicola Musatti
David Abrahams wrote:
on Tue May 01 2007, "Peter Dimov" <pdimov-AT-mmltd.net> wrote:
Jeff Garland wrote:
BTW, I don't know if this has been discussed much, but the plan for subversion switchover, as I understand it, is to take 1.34 as the svn HEAD and force all work unstable stuff on the CVS HEAD to be brought over using the new process.
That would be very impolite. :-)
I'm not sure this transition *can* be a "polite" process if it's going to work. That said, I'm open to suggestions.
Let me get this straight... you will be throwing all of my post-1.34 changes away with the transition? What are the expected benefits of this move?
Peter Dimov wrote:
David Abrahams wrote:
on Tue May 01 2007, "Peter Dimov" <pdimov-AT-mmltd.net> wrote:
Jeff Garland wrote:
BTW, I don't know if this has been discussed much, but the plan for subversion switchover, as I understand it, is to take 1.34 as the svn HEAD and force all work unstable stuff on the CVS HEAD to be brought over using the new process. That would be very impolite. :-) I'm not sure this transition *can* be a "polite" process if it's going to work. That said, I'm open to suggestions.
Let me get this straight... you will be throwing all of my post-1.34 changes away with the transition? What are the expected benefits of this move?
In my reading there is a big difference between 'bring over' and 'throw away'. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
On May 2, 2007, at 8:37 AM, Peter Dimov wrote:
David Abrahams wrote:
on Tue May 01 2007, "Peter Dimov" <pdimov-AT-mmltd.net> wrote:
Jeff Garland wrote:
BTW, I don't know if this has been discussed much, but the plan for subversion switchover, as I understand it, is to take 1.34 as the svn HEAD and force all work unstable stuff on the CVS HEAD to be brought over using the new process.
That would be very impolite. :-)
I'm not sure this transition *can* be a "polite" process if it's going to work. That said, I'm open to suggestions.
Let me get this straight... you will be throwing all of my post-1.34 changes away with the transition? What are the expected benefits of this move?
The current CVS HEAD would go into a branch in Subversion (say, branches/post-1.34-head). The 1.34.0 release branch would become the development branch. Of course, developers will need to merge changes over from branches/post-1.34-head to the development branch. Yes, it's a pain. However, my experience with managing the 1.33 release series (and watching the 1.34 release series) tells me that this is the right way forward. With each release, effort has gone into bug-fixes for the release branch while HEAD has become the Wild West, literally falling apart in the interim. It took months of stabilizing HEAD to get to the point where we could branch the 1.33 release, many more months to to re-stabilize HEAD for the 1.34 release, and the time is proportional to the time that the release branch is active. How long will it take to stabilize HEAD post-1.34? If we're going to break the cycle of longer and longer releases, we need to start each release from a clean slate... which means, in this case, starting from the previous release and carefully merging changes over from post-1.34-head to the development branch. - Doug
Doug Gregor wrote:
Yes, it's a pain. However, my experience with managing the 1.33 release series (and watching the 1.34 release series) tells me that this is the right way forward. With each release, effort has gone into bug-fixes for the release branch while HEAD has become the Wild West, literally falling apart in the interim.
I understand the reasoning. But consider the point of view of someone whose portions of HEAD are as stable as the 1.34 branch. He is now being punished for doing his job well.
On May 2, 2007, at 9:08 AM, Peter Dimov wrote:
Doug Gregor wrote:
Yes, it's a pain. However, my experience with managing the 1.33 release series (and watching the 1.34 release series) tells me that this is the right way forward. With each release, effort has gone into bug-fixes for the release branch while HEAD has become the Wild West, literally falling apart in the interim.
I understand the reasoning. But consider the point of view of someone whose portions of HEAD are as stable as the 1.34 branch. He is now being punished for doing his job well.
I know. I, too, have a bunch of stable code on HEAD that is going to be a pain to move over. To help ease this transition, I'll come up with the appropriate "svn merge" commands to make it easy to pull changes from HEAD into the development branch. Then, it should be only a small matter to test them locally and commit them to the development branch. If someone does cause problems with such a commit, Subversion makes it very, very ease to revert those changes... and we will. - Doug
Doug Gregor <dgregor <at> osl.iu.edu> writes: [...]
I know. I, too, have a bunch of stable code on HEAD that is going to be a pain to move over. To help ease this transition, I'll come up with the appropriate "svn merge" commands to make it easy to pull changes from HEAD into the development branch. Then, it should be only a small matter to test them locally and commit them to the development branch. If someone does cause problems with such a commit, Subversion makes it very, very ease to revert those changes... and we will.
Excuse me, but aren't we supposed to be moving towards Beman's new process? If that's the case, I'm not sure I understand the way you're naming the future subversion branches. The way I see it the current CVS HEAD will become svn development, i.e. the place where things are allowed to break for short periods; 1.34 on the other hand is going to become the starting point for the svn stable branch, where commits are immediately backed out if they cause regressions. If I'm right then, while I understand Peter's concerns, I see no other way to proceed; removing unstable stuff from HEAD sounds much more painful, if feasible at all. Given how long development on HEAD has gone forward with respect to 1.34 I wonder if it wouldn't be a good idea to try and put together a schedule for the merge of currently stable libraries, so as to ensure each lot doesn't indeed cause any regression before the next one goes in. We could start with the libraries that are already present in 1.34 and then move on to the newer ones. A tightly controlled approach might result in shorter delays, while avoiding Jeff's stricter approach of leaving out of 1.35 any evolution of existing libraries. Cheers, Nicola Musatti
On May 2, 2007, at 9:55 AM, Nicola Musatti wrote:
Doug Gregor <dgregor <at> osl.iu.edu> writes: [...]
I know. I, too, have a bunch of stable code on HEAD that is going to be a pain to move over. To help ease this transition, I'll come up with the appropriate "svn merge" commands to make it easy to pull changes from HEAD into the development branch. Then, it should be only a small matter to test them locally and commit them to the development branch. If someone does cause problems with such a commit, Subversion makes it very, very ease to revert those changes... and we will.
Excuse me, but aren't we supposed to be moving towards Beman's new process? If that's the case, I'm not sure I understand the way you're naming the future subversion branches. The way I see it the current CVS HEAD will become svn development, i.e. the place where things are allowed to break for short periods; 1.34 on the other hand is going to become the starting point for the svn stable branch, where commits are immediately backed out if they cause regressions.
*Sigh*. This is why it's better to look at concrete proposals than to discuss without them... we all assume different things about the unsaid details. When we release 1.34.0, we switch to Subversion. The repository layout (documented at http://svn.boost.org/trac/boost/wiki/ BoostSubversion) contains two branches, "stable" and "devel". Changes go into devel first, get tested, then migrate to the "release-ready" stable branch. IIRC, this is one of the recommendations in Beman's proposal, and it's much easier to enforce in the world of Subversion. When we switch to Subversion, the 1.34.0 release branch becomes both "stable" and "devel", giving us a clean slate. The current CVS HEAD becomes a branch (branches/post-1.34-head). Developers can migrate changes from post-1.34-head to "devel", where they will be tested, fixed, and eventually moved to "stable" for a release. - Doug
Doug Gregor wrote:
When we release 1.34.0, we switch to Subversion. The repository layout (documented at http://svn.boost.org/trac/boost/wiki/ BoostSubversion) contains two branches, "stable" and "devel". Changes go into devel first, get tested, then migrate to the "release-ready" stable branch. IIRC, this is one of the recommendations in Beman's proposal, and it's much easier to enforce in the world of Subversion.
One thing that is 'merely' a matter of good engineering practice, but which Subversion makes much easier through atomic commits, is that changesets should be minimal and self-contained, and never contain unrelated changes. This helps tremendously when merging changesets across branches, and figuring out a cause of a regression (say). FWIW, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Doug Gregor <dgregor <at> osl.iu.edu> writes: [...]
*Sigh*. This is why it's better to look at concrete proposals than to discuss without them... we all assume different things about the unsaid details.
I don't mean to pick on you, but this appears to be a recurring problem. Hopefully the new Boost Trac will help mitigate it. Well, not by itself, but by becoming, with everybody's help, more central to Boost development than the current wiki is. [...]
When we switch to Subversion, the 1.34.0 release branch becomes both "stable" and "devel", giving us a clean slate. The current CVS HEAD becomes a branch (branches/post-1.34-head). Developers can migrate changes from post-1.34-head to "devel", where they will be tested, fixed, and eventually moved to "stable" for a release.
I see. It does appear safer than what I was expecting, at the expense of somewhat increased effort. I don't have any objection, but then I also don't have any code in HEAD :-0 Cheers, Nicola Musatti
On May 2, 2007, at 11:31 AM, Nicola Musatti wrote:
Doug Gregor <dgregor <at> osl.iu.edu> writes: [...]
*Sigh*. This is why it's better to look at concrete proposals than to discuss without them... we all assume different things about the unsaid details.
I don't mean to pick on you, but this appears to be a recurring problem.
Beman promised to bring forward an updated proposal, and we're discussing it before he had the chance. Let's wait. - Doug
"Doug Gregor" <dgregor@osl.iu.edu> wrote in message news:B544C55C-9230-4562-A43C-3DC5862B9F70@osl.iu.edu...
On May 2, 2007, at 9:08 AM, Peter Dimov wrote:
Doug Gregor wrote:
Yes, it's a pain. However, my experience with managing the 1.33 release series (and watching the 1.34 release series) tells me that this is the right way forward. With each release, effort has gone into bug-fixes for the release branch while HEAD has become the Wild West, literally falling apart in the interim.
I understand the reasoning. But consider the point of view of someone whose portions of HEAD are as stable as the 1.34 branch. He is now being punished for doing his job well.
I know. I, too, have a bunch of stable code on HEAD that is going to be a pain to move over. To help ease this transition, I'll come up with the appropriate "svn merge" commands to make it easy to pull changes from HEAD into the development branch. Then, it should be only a small matter to test them locally and commit them to the development branch. If someone does cause problems with such a commit, Subversion makes it very, very ease to revert those changes... and we will.
Two questions: 1. Does anyone could tell me, if I have any code I need to merge? 2. How soon "revert" is triggered? I mean, let's say I committed some code that I tested only on compilers I have access to and it fails on others how much time do I have to fix? Gennadiy
On May 2, 2007, at 10:25 AM, Gennadiy Rozental wrote:
Two questions:
1. Does anyone could tell me, if I have any code I need to merge?
It will be very easy to tell once we've moved to Subversion... it's just a simple "diff" operation between two branches.
2. How soon "revert" is triggered? I mean, let's say I committed some code that I tested only on compilers I have access to and it fails on others how much time do I have to fix?
I assume Beman will propose something specific. In GCC, when someone breaks something significant in the build, two maintainers can agree to start a 48-hour reversion counter. If the bug isn't fixed in that time, one of the maintainers would revert the patch. GCC maintainers rarely ever revert patches. In part, it's because they have a rigid peer-review system for code already in the repository. Mostly, however, it's because submitters fix problems that come up as soon as the problem is reported. In Boost, I expect reversion to be rare, and certainly won't occur when problems only pop up because of compilers that the submitter can't test locally. - Doug
"Doug Gregor" <dgregor@osl.iu.edu> wrote in message news:570B52D0-A9B4-482F-9C1B-35032F884F86@osl.iu.edu...
On May 2, 2007, at 10:25 AM, Gennadiy Rozental wrote:
Two questions:
1. Does anyone could tell me, if I have any code I need to merge?
It will be very easy to tell once we've moved to Subversion... it's just a simple "diff" operation between two branches.
Could we run diff for whole tree and create the list of libraries/headers that need to be merged?
2. How soon "revert" is triggered? I mean, let's say I committed some code that I tested only on compilers I have access to and it fails on others how much time do I have to fix?
I assume Beman will propose something specific. In GCC, when someone breaks something significant in the build, two maintainers can agree to start a 48-hour reversion counter. If the bug isn't fixed in that time, one of the maintainers would revert the patch.
In my experience the regression test response period is MUCH longer. Gennadiy
on Wed May 02 2007, "Gennadiy Rozental" <gennadiy.rozental-AT-thomson.com> wrote:
"Doug Gregor" <dgregor@osl.iu.edu> wrote in message news:570B52D0-A9B4-482F-9C1B-35032F884F86@osl.iu.edu...
On May 2, 2007, at 10:25 AM, Gennadiy Rozental wrote:
Two questions:
1. Does anyone could tell me, if I have any code I need to merge?
It will be very easy to tell once we've moved to Subversion... it's just a simple "diff" operation between two branches.
Could we run diff for whole tree and create the list of libraries/headers that need to be merged?
You can do that if you want. There's no need for anyone else to do it; most other people wouldn't have any use for that much data anyway. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
Doug Gregor wrote:
On May 2, 2007, at 8:37 AM, Peter Dimov wrote:
on Tue May 01 2007, "Peter Dimov" <pdimov-AT-mmltd.net> wrote:
Jeff Garland wrote:
BTW, I don't know if this has been discussed much, but the plan for subversion switchover, as I understand it, is to take 1.34 as the svn HEAD and force all work unstable stuff on the CVS HEAD to be brought over using the new process. That would be very impolite. :-) I'm not sure this transition *can* be a "polite" process if it's going to work. That said, I'm open to suggestions. Let me get this straight... you will be throwing all of my
David Abrahams wrote: post-1.34 changes away with the transition? What are the expected benefits of this move?
The current CVS HEAD would go into a branch in Subversion (say, branches/post-1.34-head). The 1.34.0 release branch would become the development branch. Of course, developers will need to merge changes over from branches/post-1.34-head to the development branch.
I thought the current head was to go in devel?
Yes, it's a pain. However, my experience with managing the 1.33 release series (and watching the 1.34 release series) tells me that this is the right way forward. With each release, effort has gone into bug-fixes for the release branch while HEAD has become the Wild West, literally falling apart in the interim. It took months of stabilizing HEAD to get to the point where we could branch the 1.33 release, many more months to to re-stabilize HEAD for the 1.34 release, and the time is proportional to the time that the release branch is active. How long will it take to stabilize HEAD post-1.34? If we're going to break the cycle of longer and longer releases, we need to start each release from a clean slate... which means, in this case, starting from the previous release and carefully merging changes over from post-1.34-head to the development branch.
That isn't at all what I had in mind. Rather, a release, say 1.35 would start with the previous release - 1.34 in this case. Developers, who have been working in devel (which is equivalent to the old HEAD), branch/tag their code at the point they think it is OK as "stable". Then when it comes time to do a release a script run by the release manager tries to merge code for the library from "stable" to the release candidate branch (working in library dependency order, with cycles broken when necessary). Tests are run. If there are failures, the script reverts the broken library, and moves on. We might do something like give developers a fixed period of time (a week? 10 days?) to fix "stable", but when the merge/test/revert-if-needed script is run again, any libraries that are still failing don't make it into the current release. That procedure would preserve all of Peter's and other developers hard work in HEAD, and that work would go into 1.35 as long as it passes the regression tests. --Beman
On Wed, 2007-05-02 at 18:30 -0400, Beman Dawes wrote:
That isn't at all what I had in mind. Rather, a release, say 1.35 would start with the previous release - 1.34 in this case. Developers, who have been working in devel (which is equivalent to the old HEAD), branch/tag their code at the point they think it is OK as "stable". Then when it comes time to do a release a script run by the release manager tries to merge code for the library from "stable" to the release candidate branch (working in library dependency order, with cycles broken when necessary).
I'm a bit confused... is "stable" a branch, or just a way to refer to certain points in the development of a library?
Tests are run. If there are failures, the script reverts the broken library, and moves on. We might do something like give developers a fixed period of time (a week? 10 days?) to fix "stable", but when the merge/test/revert-if-needed script is run again, any libraries that are still failing don't make it into the current release.
I'm very skeptical of any process that depends on an automatic merge/revert script. Such a script will require a huge amount of effort to develop and maintain (particularly because it needs dependency information) and is going to require intervention for non-trivial merge cases. Anyway, I should wait until I read your proposal before commenting further. I don't think we should wait until 1.34.0 is out the door before discussing the proposal, because once 1.34.0 is out there I'd like to switch to Subversion shortly thereafter, and the Subversion layout should reflect our updated process. - Doug
Douglas Gregor wrote:
Anyway, I should wait until I read your proposal before commenting further. I don't think we should wait until 1.34.0 is out the door before discussing the proposal, because once 1.34.0 is out there I'd like to switch to Subversion shortly thereafter, and the Subversion layout should reflect our updated process.
But luckily with subversion we don't need to Get It Right the first time. The switch to subversion is but the very first step. Adjusting the layout of the repository can be an incremental process. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
on Fri May 04 2007, Douglas Gregor <doug.gregor-AT-gmail.com> wrote:
On Wed, 2007-05-02 at 18:30 -0400, Beman Dawes wrote:
That isn't at all what I had in mind. Rather, a release, say 1.35 would start with the previous release - 1.34 in this case. Developers, who have been working in devel (which is equivalent to the old HEAD), branch/tag their code at the point they think it is OK as "stable". Then when it comes time to do a release a script run by the release manager tries to merge code for the library from "stable" to the release candidate branch (working in library dependency order, with cycles broken when necessary).
I'm a bit confused... is "stable" a branch, or just a way to refer to certain points in the development of a library?
What's the difference (in the SVN world)? -- Dave Abrahams Boost Consulting www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
On 5/4/07, David Abrahams <dave@boost-consulting.com> wrote:
on Fri May 04 2007, Douglas Gregor <doug.gregor-AT-gmail.com> wrote:
On Wed, 2007-05-02 at 18:30 -0400, Beman Dawes wrote:
That isn't at all what I had in mind. Rather, a release, say 1.35 would start with the previous release - 1.34 in this case. Developers, who have been working in devel (which is equivalent to the old HEAD), branch/tag their code at the point they think it is OK as "stable". Then when it comes time to do a release a script run by the release manager tries to merge code for the library from "stable" to the release candidate branch (working in library dependency order, with cycles broken when necessary).
I'm a bit confused... is "stable" a branch, or just a way to refer to certain points in the development of a library?
What's the difference (in the SVN world)?
An possible SVN organization could look like the following: -trunk/src ... tree -branches/1.34/trunk/src ... tree -branches/1.34/builds/001/src ... tree -branches/1.34/builds/002/src ... tree .... etc. The trunk at the "root" sort of corresponds to the CVS main branch. They are very much like directories. For example, at certain point when 1.35 is to be branched, the admin or one with the privilege simply svn make directory "branches/1.35/trunk" and then svn cp --recursive "trunk/src ... tree" to there (not exact commands, just the idea). Now the whole becomes -trunk/src ... tree -branches/1.34/trunk/src ... tree -branches/1.34/builds/001/src ... tree -branches/1.34/builds/002/src ... tree -branches/1.35/trunk/src ... tree .... etc. Note that SVN did not really make a verbatim copy of the whole directory tree as is the case for directories in an ordinary UNIX file system. SVN just makes a note of fact with record keeping such as a new version number, but presents the results like the above. As another example, when it's time for the admin to make build 001 of 1.35, he svn-makes directory "branches/1.35/builds/001/" and then svn-copies --recursive "branches/1.35/trunk/src ... tree" to there. Now the whole thing becomes -trunk/src ... tree -branches/1.34/trunk/src ... tree -branches/1.34/builds/001/src ... tree -branches/1.34/builds/002/src ... tree -branches/1.35/trunk/src ... tree -branches/1.35/trunk/001/src ... tree .... etc. It's like a snapshot of "branches/1.35/trunk/src ... tree" was taken and placed under "branches/1.35/builds/001/". People may still check in changes to "branches/1.35/trunk/src ... tree", while "branches/1.35/builds/001/src ... tree" is only accessible to the admin responsible for the interim build 1.35-001. The same goes with "trunk/src ... tree" as the main branch, just as "branches/1.35/trunk/src ... tree" is regarded as the 1.35 branch. Hope this helps in terms of concept. -- Greg
Gregory Dai wrote:
An possible SVN organization could look like the following:
-trunk/src ... tree -branches/1.34/trunk/src ... tree -branches/1.34/builds/001/src ... tree -branches/1.34/builds/002/src ... tree .... etc.
Why do you want to tag that often ? Remember that in subversion revisions are global, i.e. to remember the state of the tree at the point of a given build, you only need to record the revision number on which a build is based on. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
On 5/4/07, Stefan Seefeld <seefeld@sympatico.ca> wrote:
Gregory Dai wrote:
An possible SVN organization could look like the following:
-trunk/src ... tree -branches/1.34/trunk/src ... tree -branches/1.34/builds/001/src ... tree -branches/1.34/builds/002/src ... tree .... etc.
Why do you want to tag that often ? Remember that in subversion revisions are global, i.e. to remember the state of the tree at the point of a given build, you only need to record the revision number on which a build is based on.
Well, that's only an example. It could be three months between 001 and 002. It's up to the admin according to build plan. Greg
on Sat May 05 2007, "Gregory Dai" <gregory.dai-AT-gmail.com> wrote:
On 5/4/07, David Abrahams <dave@boost-consulting.com> wrote:
on Fri May 04 2007, Douglas Gregor <doug.gregor-AT-gmail.com> wrote:
On Wed, 2007-05-02 at 18:30 -0400, Beman Dawes wrote:
That isn't at all what I had in mind. Rather, a release, say 1.35 would start with the previous release - 1.34 in this case. Developers, who have been working in devel (which is equivalent to the old HEAD), branch/tag their code at the point they think it is OK as "stable". Then when it comes time to do a release a script run by the release manager tries to merge code for the library from "stable" to the release candidate branch (working in library dependency order, with cycles broken when necessary).
I'm a bit confused... is "stable" a branch, or just a way to refer to certain points in the development of a library?
What's the difference (in the SVN world)?
<snip long explanation>
Hope this helps in terms of concept.
Thanks. Though I know how SVN works (which is sorta why I asked the question), I'm sure the elaboration will be useful to many here. I guess you're saying that if "stable" was a branch, people would be doing direct development there, and if not, people would periodically "svn cp" code from their development branch into stable. Seems like we want the latter; i.e. "stable" is not a branch. -- Dave Abrahams Boost Consulting www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
On May 4, 2007, at 8:35 PM, David Abrahams wrote:
on Fri May 04 2007, Douglas Gregor <doug.gregor-AT-gmail.com> wrote:
On Wed, 2007-05-02 at 18:30 -0400, Beman Dawes wrote:
That isn't at all what I had in mind. Rather, a release, say 1.35 would start with the previous release - 1.34 in this case. Developers, who have been working in devel (which is equivalent to the old HEAD), branch/tag their code at the point they think it is OK as "stable". Then when it comes time to do a release a script run by the release manager tries to merge code for the library from "stable" to the release candidate branch (working in library dependency order, with cycles broken when necessary).
I'm a bit confused... is "stable" a branch, or just a way to refer to certain points in the development of a library?
What's the difference (in the SVN world)?
What I meant was: is "stable" some snapshot of Boost (as a whole) that we'll be running regression tests on, or is it just some kind of library-specific label that is transient and used only to merge things into the current release branch? - Doug
Jeff Garland wrote:
It wouldn't be for long b/c the end date of the release would be fixed :-) And maybe now is the time to try and find a few more regression runners so we can do more branches at once.
I think the problem here could be MetaComm resources. If we start testing multiple branches, then I fear for the turnaround time for the results pages. Which is not to say MetaComm are not doing a fabulous job for us - far from it, I would be lost without them! But this is a single resource that we place a high demand on - and more testers will simply stress them further. -- AlisdairM
on Tue May 01 2007, "AlisdairM" <alisdair.meredith-AT-uk.renaultf1.com> wrote:
Jeff Garland wrote:
It wouldn't be for long b/c the end date of the release would be fixed :-) And maybe now is the time to try and find a few more regression runners so we can do more branches at once.
I think the problem here could be MetaComm resources. If we start testing multiple branches, then I fear for the turnaround time for the results pages.
Which is not to say MetaComm are not doing a fabulous job for us - far from it, I would be lost without them! But this is a single resource that we place a high demand on - and more testers will simply stress them further.
One of the things we hope to address in http://boostcon.com/program/sessions#rivera-testing-sprint -- Dave Abrahams Boost Consulting http://www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
David Abrahams wrote:
One of the things we hope to address in http://boostcon.com/program/sessions#rivera-testing-sprint
Unfortunately I can't be there, so I'll pitch in my idea now! If we are looking at testing more branches (big if) it would be nice to have a collected page for 'oddball' branches. For instance, my Borland tests on HEAD are heavily patched on top of HEAD and there is no way to easily test this (and view results) without posting back to the HEAD page. [Note I AM keeping up to date with HEAD, just testing additional workarounds befeore posting patches] -- AlisdairM
AlisdairM wrote:
David Abrahams wrote:
One of the things we hope to address in http://boostcon.com/program/sessions#rivera-testing-sprint
Unfortunately I can't be there, so I'll pitch in my idea now!
Please pitch those ideas directly to me so that I can integrate them into the session. And very important please send them to the email mentioned on the session description, as that guarantees I have access to the email at the conference. And please do so ASAP since I have to spend some considerable time evaluating any tools and procedures in the next few days. -- -- 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
on Tue May 01 2007, "Peter Dimov" <pdimov-AT-mmltd.net> wrote:
Jeff Garland wrote:
The bottleneck I see is the regression testers. Right now Thomas needs them to keep running against 1.34 for final patches he's adding in. Going forward, I believe we will need significant time and energy from the regression runners as we test the subversion switchover. What I'd like to see happen is that instead of going back to main branch after Thomas is done we swap the regression testers over to the 1.35 branch immediately. The folks testing main can be the first beta-testers for subversion switchover.
The problem with this scheme - from a library developer point of view - is that one cannot experiment with new features since nobody is testing HEAD. One possible outcome is then for 1.35 to become a de-facto HEAD and absorb most of the new development.
Actually, the plan -- at least the plan Doug suggested and I agreed to -- was to make 1.34 the de-facto head, so we have something regression-free to start with. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
Jeff Garland wrote:
I've been rabble rousing behind the scenes to get authors to get their libs checked into CVS. We have a couple libs: asio and xpressive whose regressions are already clean on several of the release compilers. We need to get the other new libs into the regression test suite so we can assess their state. Eric and Chris can start working on markup/changes for the other regressions, etc, etc.
Xpressive is not a concern for 1.35. It's in 1.34. Just so you know. -- Eric Niebler Boost Consulting www.boost-consulting.com
Nicola Musatti wrote:
Jeff Garland wrote: [...]
I believe this is urgent because a major backlog of unreleased Boost code has now developed. The asio review was 1.5 years ago -- it's hard to fathom that it's not in a release yet. It's simply not acceptable to wait even 3 months more to get asio and other 'new' libs into a boost release. And besides, asio and the libs above are really just the short list: there's xpressive, GIL, bimap, accumulators, function types, and units that have been accepted now -- huge and important libraries. And it's not stopping, there's a review backlog, a pile of SoC projects, etc. We have to dramatically shorten the release cycle to get these libraries out into a release.
I believe there are to sides to this: one is to come out with 1.35 as fast as possible to make up for lost time, the other is to ensure that such delays do not happen again. In this respect I'm afraid that Beman's approach shares with the current one too much reliance on self discipline and team cohesion. Boost is too large and too intertwined to rely so much on self discipline and team cohesion simply is not there, apart possibly among a small number of veteran core developers. Witness for instance how many were taken by surprise by the switch to BBv2.
I agree with you and have been working on a modified version of the approach I proposed a year ago. It does not depend on self discipline to nearly as great an extent. I haven't wanted to distract from the effort to ship 1.34, so haven't been posting suggested changes to my original proposal. But expect a revised proposal from me within a few days of 1.34 shipping. --Beman
Beman Dawes <bdawes <at> acm.org> writes: [...]
I agree with you and have been working on a modified version of the approach I proposed a year ago. It does not depend on self discipline to nearly as great an extent.
I'm glad to hear that you share my concerns. I'm convinced that the current process is in dire need of improvement and the approach you suggested appears to me as a start in a right direction, provided a little more steering is added to it.
I haven't wanted to distract from the effort to ship 1.34, so haven't been posting suggested changes to my original proposal. But expect a revised proposal from me within a few days of 1.34 shipping.
I understand, but given the present discussion I'd urge you to anticipate your revised proposal, assuming you're ready to do it. Cheers, Nicola Musatti
Jeff Garland wrote:
Now, I realize that we have a plan to switch to subversion and have a new process that has been developed by Beman, etc. But it's my view that we should pursue a CVS based approach because it requires zero time to implement. In the meantime the subversion conversion can proceed in parallel. When everything is 100% ready to go we switch. My worry is that the conversion of regression testing, developers, and all other release process changes will wind up delaying 1.35 by several months. Of course, if my pessimism is misplaced then we can switch to subversion for the 1.35 release. Nothing will have been lost because we will have been testing new libs for 1.35 anyway.
I disagree. The one thing I've learned from the various Boost release, and general development, is that developers will not do "parallel" if they can avoid it. There are various reasons for this, but the most obvious one is that people have very little time to volunteer. Hence if we make the Subversion switch an additional task for people it will take a long time to complete, because we just don't have enough people resources. -- -- 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
Rene Rivera wrote:
Jeff Garland wrote:
Now, I realize that we have a plan to switch to subversion and have a new process that has been developed by Beman, etc. But it's my view that we should pursue a CVS based approach because it requires zero time to implement. In the meantime the subversion conversion can proceed in parallel. When everything is 100% ready to go we switch. My worry is that the conversion of regression testing, developers, and all other release process changes will wind up delaying 1.35 by several months. Of course, if my pessimism is misplaced then we can switch to subversion for the 1.35 release. Nothing will have been lost because we will have been testing new libs for 1.35 anyway.
I disagree. The one thing I've learned from the various Boost release, and general development, is that developers will not do "parallel" if they can avoid it. There are various reasons for this, but the most obvious one is that people have very little time to volunteer.
Sure, however, I don't think we're talking about the same people. What are the authors of asio, gil, interprocess, etc going to do with the regression scripts for the the subversion switch other? I doubt it's going to be much. In the meantime, we don't want them sitting idle, we want to get them the testing going and let them get to work on any porting issues.
Hence if we make the Subversion switch an additional task for people it will take a long time to complete, because we just don't have enough people resources.
I agree we lack resources, but if we put conversion in front of testing new libs for 1.35, that, in itself, won't make it go any faster. That's the main mistake we keep making. Just because you 'serialize the activity' doesn't make it happen faster. What we need to recruit additional people resources to do the work: go fix a web page, test out a script, etc. Right now, AFAICT, we have one very busy man (Doug Gregor) that is the only person working toward the subversion switchover. Doug is a hugely capable person, but he is really busy and he's going to need help. Jeff
On May 1, 2007, at 10:42 AM, Jeff Garland wrote:
I agree we lack resources, but if we put conversion in front of testing new libs for 1.35, that, in itself, won't make it go any faster. That's the main mistake we keep making. Just because you 'serialize the activity' doesn't make it happen faster. What we need to recruit additional people resources to do the work: go fix a web page, test out a script, etc. Right now, AFAICT, we have one very busy man (Doug Gregor) that is the only person working toward the subversion switchover. Doug is a hugely capable person, but he is really busy and he's going to need help.
Our sysadmin, Dong Inn, has been doing the vast majority of the work to get us moved over to SVN and Trac. I just end up doing the bits that are visible from the Boost side. - Doug
Jeff Garland writes: [...]
Now, I realize that we have a plan to switch to subversion and have a new process that has been developed by Beman, etc. But it's my view that we should pursue a CVS based approach because it requires zero time to implement. In the meantime the subversion conversion can proceed in parallel. When everything is 100% ready to go we switch.
</delurk> A minor point in this discussion, but: Switching to SVN is _not_ going to go completely smoothly, it _will_ take some resources and time, it _will_ annoy people for a while; see for example the experience the GCC developers had during their switch. On the other hand, we switched from CVS to SubVersion several years ago; our experience was not unlike the GCC developers (although the whole thing took less time, we're a small company). And we're very, very happy we did so. In our experience, it's like pulling off a band-aid; it's unpleasant, it's inevitable, so it's best to get it done as quickly as possible. My advice would be to A) accept that switching will take some time and trouble and B) to get it done as soon and as quickly as possible. </lurk> ---------------------------------------------------------------------- Dave Steffen, Ph.D. Fools ignore complexity. Software Engineer IV Pragmatists suffer it. Numerica Corporation Some can avoid it. ph (970) 461-2000 x227 Geniuses remove it. dgsteffen@numerica.us -- Alan Perlis
on Mon Apr 30 2007, Jeff Garland <jeff-AT-crystalclearsoftware.com> wrote:
Thomas Witt wrote:
In article <624789.81580.qm@web53912.mail.re2.yahoo.com> Cromwell Enage <sponage@yahoo.com> wrote:
A few somewhat-recently accepted libraries (e.g. ASIO, Fusion, Interprocess, MPI, PropertyTree) are available in both the beta distribution and via CVS but are not advertised in either libs/libraries.htm or doc/html/index.html; will their presence at least be announced in the news section of the home page during the official release?
As of now there is no such plan. They are not part of the official release and as such are not mentioned in the docs.
To clarify, none of the listed libraries are in the beta distribution I have. And property tree isn't in CVS yet AFAICS.
Most of these libraries should be in 1.35, which will hopefully be released 'quickly'. By quickly, I mean ~1.5 months...which means a beta release 1 month after 1.34. Yep, that's right, I think we need to set some very hard goals to re-energize the boost release process.
Agreed.
After the '1.34 experience' I've become even more of an advocate a hard line release approach. That is, we should set the deadline and only accept code that can make it in the release timeframe -- if it's not ready then we take it out and let it slide to the next release.
I agree in principle that it's a good approach. However: 1. letting code slip in after deadlines is not what held up 1.34. 2. You have to be careful that taking code out doesn't break more stuff than it fixes.
To minimize risk of delay and release the pent-up backlog of new libraries I believe we should hold all existing 1.34 libs constant and only add in new libraries that are basically ready to go now. I've actually done an 'alpha test' of this approach and it looks like this will work -- that is, most of the unreleased libraries can be build against a 1.34 core without dependencies on changes to existing libraries (there are a few minor exceptions). Behind the scenes I've been encouraging developers of new libs to get their code into CVS so we will be ready to begin the nano-second after 1.34 ships.
That's a fantastic idea.
Now, I realize that we have a plan to switch to subversion and have a new process that has been developed by Beman, etc. But it's my view that we should pursue a CVS based approach because it requires zero time to implement.
I think I disagree, though not strongly.
In the meantime the subversion conversion can proceed in parallel.
No it can't. The way it works is: 1. freeze CVS 2. convert it to subversion. You can't (reasonably) convert CVS to subversion, work in the subversion repo, and then somehow merge an updated CVS back into SVN. Or did you have something else in mind? The subversion repository is ready to go now.
When everything is 100% ready to go we switch. My worry is that the conversion of regression testing, developers, and all other release process changes will wind up delaying 1.35 by several months.
I agree that's a potential danger. We should look carefully at what's involved here. 1. Regression testing doesn't use (actually, doesn't require) CVS. Those optionally using CVS now can just as easily "optionally use" SVN. 2. Developers. What? Setting up passwords and accounts? 3. All other release process changes. What are they? So far I don't see any serious issues. If you can be more specific I'm open to chaning my mind.
Of course, if my pessimism is misplaced then we can switch to subversion for the 1.35 release. Nothing will have been lost because we will have been testing new libs for 1.35 anyway.
I don't understand that last sentence.
I believe this is urgent because a major backlog of unreleased Boost code has now developed. The asio review was 1.5 years ago -- it's hard to fathom that it's not in a release yet.
Agree.
It's simply not acceptable to wait even 3 months more to get asio and other 'new' libs into a boost release. And besides, asio and the libs above are really just the short list: there's xpressive, GIL, bimap, accumulators, function types, and units that have been accepted now -- huge and important libraries. And it's not stopping, there's a review backlog, a pile of SoC projects, etc. We have to dramatically shorten the release cycle to get these libraries out into a release.
Agree. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
Jeff Garland wrote:
To minimize risk of delay and release the pent-up backlog of new libraries I believe we should hold all existing 1.34 libs constant and only add in new libraries that are basically ready to go now. I've actually done an 'alpha test' of this approach and it looks like this will work -- that is, most of the unreleased libraries can be build against a 1.34 core without dependencies on changes to existing libraries (there are a few minor exceptions). Behind the scenes I've been encouraging developers of new libs to get their code into CVS so we will be ready to begin the nano-second after 1.34 ships.
If you hadn't already realised it, the documentation might require some work. ASIO and interprocess both use quickbook 1.4, which is in HEAD. Daniel
At 4:18 PM -0700 4/30/07, Cromwell Enage wrote:
A few somewhat-recently accepted libraries (e.g. ASIO, Fusion, Interprocess, MPI, PropertyTree) are available in both the beta distribution and via CVS
I don't see any of these in the beta distribution; specifically, they aren't in the tar.bz2 package I downloaded last week.
Thomas Witt wrote:
I will not accept any changes to 1.34.0 whatsoever starting Thursday May 3. Please make sure you report all problems/fixes/doc changes till then.
The attached patch adds the missing reference documentation for a partial specialization of the hash object (reported by Joaquin last week). It's not vital, but it would be nice to add. Should I check it in? If you want a better idea of what it does, it adds template<typename T> struct hash<T*>; to the list of specializations at: http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/hash/referen... Daniel
In article <f16rk4$ma9$1@sea.gmane.org> Daniel James <daniel_james@fmail.co.uk> wrote:
The attached patch adds the missing reference documentation for a partial specialization of the hash object (reported by Joaquin last week). It's not vital, but it would be nice to add. Should I check it in?
Please go ahead. Thomas
Thomas Witt wrote:
Hi,
I will not accept any changes to 1.34.0 whatsoever starting Thursday May 3. Please make sure you report all problems/fixes/doc changes till then.
Only real show stoppers (i.e. build might start thermonuclear war) will be considered after that date.
Well I found one today... Thankfully I don't think it impacts the testing results... There is a problem with the detection of the gcc/MinGW compiler for some builds of that compiler. The solution involves changing the gcc.jam toolset file. I don't have the changes yet, since I'll be busy for most of today but I'll post them later tonight. -- -- 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
participants (18)
-
AlisdairM -
Beman Dawes -
Cromwell Enage -
Daniel James -
Dave Steffen -
David Abrahams -
Doug Gregor -
Douglas Gregor -
Eric Niebler -
Gennadiy Rozental -
Gregory Dai -
Jeff Garland -
Kim Barrett -
Nicola Musatti -
Peter Dimov -
Rene Rivera -
Stefan Seefeld -
Thomas Witt