Since I don't enjoy reverting changes when I don't have the time (I'm in the middle of my own product release). And since Boost is nearing the end of a release cycle. *ALL* tool changes are hereby *FROZEN* except for emergency fixes. Any changes must be approved by Beman or myself. And such changes must include making sure Boost testing runs adequately in *both* a Windows platform and a Unix platform. This means going to the boost-root/status directory and running the tests for *at least one* library, but preferably all of them. Thank you for paying attention. -- -- 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:
Since I don't enjoy reverting changes when I don't have the time (I'm in the middle of my own product release). And since Boost is nearing the end of a release cycle. *ALL* tool changes are hereby *FROZEN* except for emergency fixes. Any changes must be approved by Beman or myself. And such changes must include making sure Boost testing runs adequately in *both* a Windows platform and a Unix platform. This means going to the boost-root/status directory and running the tests for *at least one* library, but preferably all of them.
Thank you for paying attention.
Pardon me, but what the hell? Do I really need to explain that branches in version control systems are intended specifically so that you don't have to *SHOUT IN EMPHASIZED UPPERCASE* whenever development branch, also known as trunk, gets broke? Or do we to understand that 1.36.0 beta 1, which is due due days ago, is going to be rolled from trunk? Or for some unknown reason, the testing process for release branch uses tools from random other branch? - Volodya
Vladimir Prus wrote:
Rene Rivera wrote:
Since I don't enjoy reverting changes when I don't have the time (I'm in the middle of my own product release). And since Boost is nearing the end of a release cycle. *ALL* tool changes are hereby *FROZEN* except for emergency fixes. Any changes must be approved by Beman or myself. And such changes must include making sure Boost testing runs adequately in *both* a Windows platform and a Unix platform. This means going to the boost-root/status directory and running the tests for *at least one* library, but preferably all of them.
Thank you for paying attention.
Pardon me, but what the hell? Do I really need to explain that branches in version control systems are intended specifically so that you don't have to *SHOUT IN EMPHASIZED UPPERCASE* whenever development branch, also known as trunk, gets broke? Or do we to understand that 1.36.0 beta 1, which is due due days ago, is going to be rolled from trunk? Or for some unknown reason, the testing process for release branch uses tools from random other branch?
1. Trunk is not the "development" branch. We've said in the past, as part of the new release procedures, that it should be maintained in a stable form. And that "development" should be done in branches as needed by individuals. This hold for tools just as much as it holds for libraries. 2. Testing uses the BBv2 tools from trunk because it's been pointed out before, not sure if it was you, that the trunk BBv2 tools should be the ones released with the Boost releases. Hence we need to test with those tools. I'm more than happy to have a BBv2 release that we could use for testing that is sufficiently stable and has all the needed fixes for a Boost release. PS. Sorry I'm a bit irritable... I've been working on 14 hour days recently :-( -- -- 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
on Fri Jul 18 2008, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
Vladimir Prus wrote:
Rene Rivera wrote:
Since I don't enjoy reverting changes when I don't have the time (I'm in the middle of my own product release). And since Boost is nearing the end of a release cycle. *ALL* tool changes are hereby *FROZEN* except for emergency fixes. Any changes must be approved by Beman or myself. And such changes must include making sure Boost testing runs adequately in *both* a Windows platform and a Unix platform. This means going to the boost-root/status directory and running the tests for *at least one* library, but preferably all of them.
Thank you for paying attention.
Pardon me, but what the hell? Do I really need to explain that branches in version control systems are intended specifically so that you don't have to *SHOUT IN EMPHASIZED UPPERCASE* whenever development branch, also known as trunk, gets broke? Or do we to understand that 1.36.0 beta 1, which is due due days ago, is going to be rolled from trunk? Or for some unknown reason, the testing process for release branch uses tools from random other branch?
1. Trunk is not the "development" branch. We've said in the past, as part of the new release procedures, that it should be maintained in a stable form. And that "development" should be done in branches as needed by individuals. This hold for tools just as much as it holds for libraries.
I've said that over and over, but I don't remember ever reaching consensus on it. Regardless, I don't think we can expect such an important policy to stick unless we can point at a web page that says so. Care to build one? -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote: > on Fri Jul 18 2008, Rene Rivera <grafikrobot-AT-gmail.com> wrote: > >> Vladimir Prus wrote: >>> Rene Rivera wrote: >>> >>>> Since I don't enjoy reverting changes when I don't have the time (I'm in >>>> the middle of my own product release). And since Boost is nearing the >>>> end of a release cycle. *ALL* tool changes are hereby *FROZEN* except >>>> for emergency fixes. Any changes must be approved by Beman or myself. >>>> And such changes must include making sure Boost testing runs adequately >>>> in *both* a Windows platform and a Unix platform. This means going to >>>> the boost-root/status directory and running the tests for *at least one* >>>> library, but preferably all of them. >>>> >>>> Thank you for paying attention. >>> Pardon me, but what the hell? Do I really need to explain that branches in >>> version control systems are intended specifically so that you don't have >>> to *SHOUT IN EMPHASIZED UPPERCASE* whenever development branch, also known as >>> trunk, gets broke? Or do we to understand that 1.36.0 beta 1, which is due >>> due days ago, is going to be rolled from trunk? Or for some unknown reason, >>> the testing process for release branch uses tools from random other branch? >> 1. Trunk is not the "development" branch. We've said in the past, as >> part of the new release procedures, that it should be maintained in a >> stable form. And that "development" should be done in branches as >> needed by individuals. This hold for tools just as much as it holds >> for libraries. > > I've said that over and over, but I don't remember ever reaching > consensus on it. Regardless, I don't think we can expect such an > important policy to stick unless we can point at a web page that says > so. Care to build one? Well it was part of the reworked release plans: <http://svn.boost.org/trac/boost/wiki/ImprovingPractices#Trunk> <http://svn.boost.org/trac/boost/wiki/ImprovingPractices#DevelopmentCycle> Although it does say trunk is closer to a "stable development" branch. But it does make it clear most work should be done in other branches. Should I make a different page? Perhaps this is one of those situations where the "trunk" term is so overwhelmingly prejudiced to mean a free-for-all branch that it's better to just rename it to something else. And move libraries to "modular" (referred to in the past as per library) branches, like the sandbox, and how I've been suggesting for years now. -- -- 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
On Fri, Jul 18, 2008 at 4:18 PM, David Abrahams <dave@boostpro.com> wrote:
on Fri Jul 18 2008, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
Vladimir Prus wrote:
Rene Rivera wrote:
Since I don't enjoy reverting changes when I don't have the time (I'm in the middle of my own product release). And since Boost is nearing the end of a release cycle. *ALL* tool changes are hereby *FROZEN* except for emergency fixes. Any changes must be approved by Beman or myself. And such changes must include making sure Boost testing runs adequately in *both* a Windows platform and a Unix platform. This means going to the boost-root/status directory and running the tests for *at least one* library, but preferably all of them.
Thank you for paying attention.
Pardon me, but what the hell? Do I really need to explain that branches in version control systems are intended specifically so that you don't have to *SHOUT IN EMPHASIZED UPPERCASE* whenever development branch, also known as trunk, gets broke? Or do we to understand that 1.36.0 beta 1, which is due due days ago, is going to be rolled from trunk? Or for some unknown reason, the testing process for release branch uses tools from random other branch?
1. Trunk is not the "development" branch. We've said in the past, as part of the new release procedures, that it should be maintained in a stable form. And that "development" should be done in branches as needed by individuals. This hold for tools just as much as it holds for libraries.
I've said that over and over, but I don't remember ever reaching consensus on it. Regardless, I don't think we can expect such an important policy to stick unless we can point at a web page that says so. Care to build one?
You know the saying, speed doesn't kill -- the sudden stop does? If the motivation for branching is to prevent interim commits of work in progress, then I suggest stating *that* as requirement. OTOH, anything that hasn't been tested should be considered work in progress, and to test a change it has to be committed to Trunk -- not only because Trunk is the thing that gets tested, but also because many changes can produce ripple effects throughout Boost. Add to that the testing lag, and it's a given: Trunk is potentially not very stable. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski <emil <at> revergestudios.com> writes:
If the motivation for branching is to prevent interim commits of work in progress, then I suggest stating *that* as requirement.
OTOH, anything that hasn't been tested should be considered work in progress, and to test a change it has to be committed to Trunk -- not only because Trunk is the thing that gets tested, but also because many changes can produce ripple effects throughout Boost. Add to that the testing lag, and it's a given: Trunk is potentially not very stable.
For what it worth, I concur. Until we have an ability to run tests against branch, trunk *is* a development area and I do not see an alternative. Gennadiy
[I though I've replied to this, but I don't see the reply -- which I definitely wrote -- neither in sent nor drafts folder. Apologies if somebody gets reply twice] Rene Rivera wrote:
Vladimir Prus wrote:
Rene Rivera wrote:
Since I don't enjoy reverting changes when I don't have the time (I'm in the middle of my own product release). And since Boost is nearing the end of a release cycle. *ALL* tool changes are hereby *FROZEN* except for emergency fixes. Any changes must be approved by Beman or myself. And such changes must include making sure Boost testing runs adequately in *both* a Windows platform and a Unix platform. This means going to the boost-root/status directory and running the tests for *at least one* library, but preferably all of them.
Thank you for paying attention.
Pardon me, but what the hell? Do I really need to explain that branches in version control systems are intended specifically so that you don't have to *SHOUT IN EMPHASIZED UPPERCASE* whenever development branch, also known as trunk, gets broke? Or do we to understand that 1.36.0 beta 1, which is due due days ago, is going to be rolled from trunk? Or for some unknown reason, the testing process for release branch uses tools from random other branch?
1. Trunk is not the "development" branch.
Well, the wiki is very clear on that: Trunk The main development and test location. So, as documented, it *is* development branch.
We've said in the past, as part of the new release procedures, that it should be maintained in a stable form. And that "development" should be done in branches as needed by individuals. This hold for tools just as much as it holds for libraries.
I don't think I know of any project that believes that it's OK for trunk to be broken (as in, regression tests failing) for a significant periods of time. But on the other hand, I don't think I know any project where issues appearing in trunk result in immediate revert of the commit. I don't think the Boost wiki documents such drastic approach either, and I don't think it should. The commit in question is an isolated commit, which is not part of any major rework supposed to caused any instability. "Developing" it on branch would be fairly weird, and given that we don't have any way to run tests on random branch, it might not prevent any mistakes.
2. Testing uses the BBv2 tools from trunk because it's been pointed out before, not sure if it was you, that the trunk BBv2 tools should be the ones released with the Boost releases. Hence we need to test with those tools. I'm more than happy to have a BBv2 release that we could use for testing that is sufficiently stable and has all the needed fixes for a Boost release.
I don't think I said exactly that. I do think that on the average, any random snapshot of Boost.Build is strictly better than either the previous release, or the state included in previous C++ Boost release, and so trunk state at some point should be automatically included in next C++ Boost release. But I never said you should use "live" trunk version for C++ Boost releases, precisely for the same reason you don't use "live" trunk version of any individual library. As soon as merge from trunk to release branch is made, the release branch version of Boost.Build should be used for testing the release, and only fixes for issues found during such testing should be further merged. There's no need to make formal release of Boost.Build, just as you don't require separate formal release of each Boost library to be included in upcoming C++ Boost release. So, what prevents using release version of Boost.Build, and other tools, for testing the release? Can you adjust the testing infrastructure to do so? - Volodya
on Tue Jul 22 2008, Vladimir Prus <vladimir-AT-codesourcery.com> wrote:
1. Trunk is not the "development" branch.
Well, the wiki is very clear on that:
Trunk The main development and test location.
So, as documented, it *is* development branch.
Which wiki (and page) are we talking about please? -- Dave Abrahams BoostPro Computing http://www.boostpro.com
AMDG David Abrahams wrote:
Well, the wiki is very clear on that:
Trunk The main development and test location.
So, as documented, it *is* development branch.
Which wiki (and page) are we talking about please?
http://svn.boost.org/trac/boost/wiki/ImprovingPractices#Trunk In Christ, Steven Watanabe
Any reply on below? - Volodya
[I though I've replied to this, but I don't see the reply -- which I definitely wrote -- neither in sent nor drafts folder. Apologies if somebody gets reply twice]
Rene Rivera wrote:
Vladimir Prus wrote:
Rene Rivera wrote:
Since I don't enjoy reverting changes when I don't have the time (I'm in the middle of my own product release). And since Boost is nearing the end of a release cycle. *ALL* tool changes are hereby *FROZEN* except for emergency fixes. Any changes must be approved by Beman or myself. And such changes must include making sure Boost testing runs adequately in *both* a Windows platform and a Unix platform. This means going to the boost-root/status directory and running the tests for *at least one* library, but preferably all of them.
Thank you for paying attention.
Pardon me, but what the hell? Do I really need to explain that branches in version control systems are intended specifically so that you don't have to *SHOUT IN EMPHASIZED UPPERCASE* whenever development branch, also known as trunk, gets broke? Or do we to understand that 1.36.0 beta 1, which is due due days ago, is going to be rolled from trunk? Or for some unknown reason, the testing process for release branch uses tools from random other branch?
1. Trunk is not the "development" branch.
Well, the wiki is very clear on that:
Trunk The main development and test location.
So, as documented, it *is* development branch.
We've said in the past, as part of the new release procedures, that it should be maintained in a stable form. And that "development" should be done in branches as needed by individuals. This hold for tools just as much as it holds for libraries.
I don't think I know of any project that believes that it's OK for trunk to be broken (as in, regression tests failing) for a significant periods of time. But on the other hand, I don't think I know any project where issues appearing in trunk result in immediate revert of the commit. I don't think the Boost wiki documents such drastic approach either, and I don't think it should.
The commit in question is an isolated commit, which is not part of any major rework supposed to caused any instability. "Developing" it on branch would be fairly weird, and given that we don't have any way to run tests on random branch, it might not prevent any mistakes.
2. Testing uses the BBv2 tools from trunk because it's been pointed out before, not sure if it was you, that the trunk BBv2 tools should be the ones released with the Boost releases. Hence we need to test with those tools. I'm more than happy to have a BBv2 release that we could use for testing that is sufficiently stable and has all the needed fixes for a Boost release.
I don't think I said exactly that. I do think that on the average, any random snapshot of Boost.Build is strictly better than either the previous release, or the state included in previous C++ Boost release, and so trunk state at some point should be automatically included in next C++ Boost release. But I never said you should use "live" trunk version for C++ Boost releases, precisely for the same reason you don't use "live" trunk version of any individual library.
As soon as merge from trunk to release branch is made, the release branch version of Boost.Build should be used for testing the release, and only fixes for issues found during such testing should be further merged. There's no need to make formal release of Boost.Build, just as you don't require separate formal release of each Boost library to be included in upcoming C++ Boost release.
So, what prevents using release version of Boost.Build, and other tools, for testing the release? Can you adjust the testing infrastructure to do so?
- Volodya
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Rene Rivera wrote:
Since I don't enjoy reverting changes when I don't have the time (I'm in the middle of my own product release). And since Boost is nearing the end of a release cycle. *ALL* tool changes are hereby *FROZEN* except for emergency fixes. Any changes must be approved by Beman or myself. And such changes must include making sure Boost testing runs adequately in *both* a Windows platform and a Unix platform. This means going to the boost-root/status directory and running the tests for *at least one* library, but preferably all of them.
Thank you for paying attention.
Whoops, I think I just accidentally screwed this up. I made changes to BoostBook and QuickBook on trunk: http://svn.boost.org/trac/boost/changeset/47861 http://svn.boost.org/trac/boost/changeset/47862 I was thinking that this "obviously" wouldn't affect the upcoming release because I didn't make any changes on the release branch. If that's not the case, then I think most people's natural inclination will lead them astray. My $0.02. Do I need to revert my change? -- Eric Niebler BoostPro Computing http://www.boostpro.com
2008/7/29 Eric Niebler <eric@boost-consulting.com>:
I was thinking that this "obviously" wouldn't affect the upcoming release because I didn't make any changes on the release branch. If that's not the case, then I think most people's natural inclination will lead them astray. My $0.02.
Do I need to revert my change?
No, there's no reason to freeze the documentation tools. Daniel
participants (8)
-
Daniel James -
David Abrahams -
Emil Dotchevski -
Eric Niebler -
Gennadiy Rozental -
Rene Rivera -
Steven Watanabe -
Vladimir Prus