Proposal for radically altered approach to releases
The current approach to getting releases ready is completely broken in my opinion. Each release requires heroic efforts by the release manager, careful attention by many developers, and endless delays until everything is just right. This is discouraging to developers and, worse yet, important library upgrades and bug fixes are taking far too long to get into user's hands. The problems with the current release approach are not caused by release managers or developers, but rather by the release system itself. It just doesn't scale up to the number of libraries now in Boost, since every library has to be ready before a release can occur. These problems will only grow worse as more libraries are added. I propose changing to a different release model, one based on always maintaining a release-ready stable branch and merging updates for individual libraries into it asynchronously. A draft proposal is available at http://mysite.verizon.net/beman/release_overview.html. I've put a fair amount of thought into this proposal, and have run some Subversion simulations to make sure it works smoothly. What do others think? --Beman
On 5/11/06, Beman Dawes <bdawes@acm.org> wrote: <pasted from proposal>
We might say Sunday and Monday are merge days, Tuesday through Friday are test days, > and Saturday is tag day. Since it is possible to automatically tell if unexpected failures have > occurred, tagging can be by automatically scheduled script.
I know you were using a simplified example and you probably had something more concrete in mind, but do consider everyone's varying timezones (you probably did, or have a solution that makes the point moot). Perhaps a SVN script that freezes stable during certain hours so that merges can't occur. Then developers don't have to check some schedule online and do the time conversion themselves. --Michael Fawcett
"Michael Fawcett" <michael.fawcett@gmail.com> wrote in message news:bc5bffe80605110802m1bf6ca76k5056fb494148ce9e@mail.gmail.com...
On 5/11/06, Beman Dawes <bdawes@acm.org> wrote:
<pasted from proposal>
We might say Sunday and Monday are merge days, Tuesday through Friday are test days, > and Saturday is tag day. Since it is possible to automatically tell if unexpected failures have > occurred, tagging can be by automatically scheduled script.
I know you were using a simplified example and you probably had something more concrete in mind, but do consider everyone's varying timezones (you probably did, or have a solution that makes the point moot). Perhaps a SVN script that freezes stable during certain hours so that merges can't occur. Then developers don't have to check some schedule online and do the time conversion themselves.
Good points. I've added a note on time slots.
Beman Dawes <bdawes <at> acm.org> writes:
The link is broken for me. I don't mind how the release is managed so long as I can use some kind of numbering system to completely identify the version of boost I have. As a minimum the overall boost version number should be incremented everytime anything in the release branch changes. I'm thinking of cases where I know my app worked with (say) boost 1_30_0 but not with 1_32_0 - I need to be able to go back to the earlier version without jumping through hoops to reconstruct the state of the release branch at a particular point in time.
"Simon Carter" <simon.carter@ttplabtech.com> wrote in message news:loom.20060511T171525-434@post.gmane.org...
Beman Dawes <bdawes <at> acm.org> writes:
The link is broken for me.
I don't mind how the release is managed so long as I can use some kind of numbering system to completely identify the version of boost I have. As a minimum the overall boost version number should be incremented everytime anything in the release branch changes.
I'm thinking of cases where I know my app worked with (say) boost 1_30_0 but not with 1_32_0 - I need to be able to go back to the earlier version without jumping through hoops to reconstruct the state of the release branch at a particular point in time.
Good point. I've added a note to that effect, and suggested a number scheme based on the current practice. Thanks, --Beman PS: I'll update the proposal on the web as soon as I work through outstanding comments.
"Beman Dawes" <bdawes@acm.org> writes:
"Simon Carter" <simon.carter@ttplabtech.com> wrote in message news:loom.20060511T171525-434@post.gmane.org...
Beman Dawes <bdawes <at> acm.org> writes:
The link is broken for me.
I don't mind how the release is managed so long as I can use some kind of numbering system to completely identify the version of boost I have. As a minimum the overall boost version number should be incremented everytime anything in the release branch changes.
I'm thinking of cases where I know my app worked with (say) boost 1_30_0 but not with 1_32_0 - I need to be able to go back to the earlier version without jumping through hoops to reconstruct the state of the release branch at a particular point in time.
Good point. I've added a note to that effect, and suggested a number scheme based on the current practice.
SVN tags each state of the repository with a sequential number, so even intermediate states can be identified with those. -- Dave Abrahams Boost Consulting www.boost-consulting.com
--- Simon Carter <simon.carter@ttplabtech.com> wrote:
Beman Dawes <bdawes <at> acm.org> writes:
This proposal looks very good to me. I've not used boost releases for years. In my experience boost developers are very motivated to fix incompatibilities if they are discovered quickly. If things drag out the enthusiasm is significantly reduced. Therefore I update and test locally at least once a week. It has been working very well for us. The proposed mechanism seems similar. My experience suggests a positive outcome. However, this will depend a lot on reasonably quick availability of regression test results. I think running tests once a week (on some platforms) is not enough.
I don't mind how the release is managed so long as I can use some kind of numbering system to completely identify the version of boost I have. As a minimum the overall boost version number should be incremented everytime anything in the release branch changes.
SVN maintains a global revision number. Does anyone know a good way of making this number available via a header file (e.g. boost/svn_revision_stable.hpp)? I.e. each time any file in the stable branch changes the header file should automatically be updated. Cheers, Ralf __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Ralf W. Grosse-Kunstleve wrote:
SVN maintains a global revision number. Does anyone know a good way of making this number available via a header file (e.g. boost/svn_revision_stable.hpp)? I.e. each time any file in the stable branch changes the header file should automatically be updated.
At minimum that should be possible with a commit script. It might not be easy ;-) -- -- 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
Ralf W. Grosse-Kunstleve wrote:
SVN maintains a global revision number. Does anyone know a good way of making this number available via a header file (e.g. boost/svn_revision_stable.hpp)? I.e. each time any file in the stable branch changes the header file should automatically be updated.
While this is probably possible, I don't think it is the right approach. If you check out from the repository you do have that number, though not as part of the sources (but somewhere in the .svn metadata. For source packages that don't contain the .svn directories, the revision number can easily be stored in a file during packaging. Regards, Stefan
Ralf W. Grosse-Kunstleve escreveu:
SVN maintains a global revision number. Does anyone know a good way of making this number available via a header file (e.g. boost/svn_revision_stable.hpp)? I.e. each time any file in the stable branch changes the header file should automatically be updated.
The keyword $Revision$ can substitute in a file the revision of the last commit to that file. But that number won't change on commits to other files. A tool is available, WCSubRev.exe, that reads the Subversion status of all files in a working copy (excluding externals), and can substitute in a file the revision of the last commit (among other things). It is usually called in build scripts while making a (tag for) release. -- Pedro Lamarão Desenvolvimento Intersix Technologies S.A. SP: (55 11 3803-9300) RJ: (55 21 3852-3240) www.intersix.com.br Your Security is our Business
Pedro Lamarão wrote:
The keyword $Revision$ can substitute in a file the revision of the last commit to that file. But that number won't change on commits to other files.
A tool is available, WCSubRev.exe, that reads the Subversion status of all files in a working copy (excluding externals), and can substitute in a file the revision of the last commit (among other things). It is usually called in build scripts while making a (tag for) release.
This is windows only as it is part of TortoiseSVN (http://tortoisesvn.tigris.org) but I'm sure it could easily be ported to other platforms. We use this for our versioning too, it is very useful. Cheers Russell
On Friday, May 12, 2006 8:43 AM +0100 Russell Hind <rh_gmane@mac.com> wrote:
This is windows only as it is part of TortoiseSVN (http://tortoisesvn.tigris.org) but I'm sure it could easily be ported to other platforms.
We use this for our versioning too, it is very useful.
I'm using this on Linux: <http://svnwcrev.tigris.org/>
"Beman Dawes" <bdawes@acm.org> wrote
The problems with the current release approach are not caused by release managers or developers, but rather by the release system itself. It just doesn't scale up to the number of libraries now in Boost, since every library has to be ready before a release can occur.
These problems will only grow worse as more libraries are added.
I think you are considering just one dimension of the problem. The other one -- the number of supported compilers is IMO equaly, if not even more, important. The broken build can be detected only after the regressions run on all the compilers. Which may be a few days (or a few weeks). To fix the build would require a few more regression cycles, and by that time new errors can (and most likely will) be introduced. Something needs to be done about compiler availability -- this is the most critical issue, IMO. Regards, Arkadiy
"Arkadiy Vertleyb" <vertleyb@hotmail.com> wrote in message news:e3vl3p$hd7$1@sea.gmane.org...
"Beman Dawes" <bdawes@acm.org> wrote
The problems with the current release approach are not caused by release managers or developers, but rather by the release system itself. It just doesn't scale up to the number of libraries now in Boost, since every library has to be ready before a release can occur.
These problems will only grow worse as more libraries are added.
I think you are considering just one dimension of the problem.
Yes, and that is deliberate.See below.
The other one -- the number of supported compilers is IMO equaly, if not even more, important. The broken build can be detected only after the regressions run on all the compilers. Which may be a few days (or a few weeks). To fix the build would require a few more regression cycles, and by that time new errors can (and most likely will) be introduced.
Something needs to be done about compiler availability -- this is the most critical issue, IMO.
Testing issues such as what compilers to support abd/or require are certainly important. Distribution issue (subsets, binaries, etc.) are also important. If we try to fix all problems at once, I am afraid we will bog down in details. IMO, the several dimensions of the general release problem are separable. Hence the focus on fixing the release model as a separate task. Thanks, --Beman
"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes:
"Beman Dawes" <bdawes@acm.org> wrote
The problems with the current release approach are not caused by release managers or developers, but rather by the release system itself. It just doesn't scale up to the number of libraries now in Boost, since every library has to be ready before a release can occur.
These problems will only grow worse as more libraries are added.
I think you are considering just one dimension of the problem.
The other one -- the number of supported compilers is IMO equaly, if not even more, important. The broken build can be detected only after the regressions run on all the compilers. Which may be a few days (or a few weeks).
Making sure that incremental testing works reliably may be the best way to address that problem. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Beman Dawes escreveu:
I've put a fair amount of thought into this proposal, and have run some Subversion simulations to make sure it works smoothly.
What do others think?
Here: "Formal releases occur on a regular schedule. The formal release procedure is simply to package up the last tagged revision of stable, publish release candidates, and decide if there are any issues serious enough to wait for the next stable tag point." If this process would contemplate a bugfix branches associated with stable tags, and if some backporting fixes effort were made, the people complaining about API stability would be happier. No need to bugfix for ever; maybe just the previous release; or whatever is confortable enough. This should just give more longevity, and a healthier old age, to each Boost release. -- Pedro Lamarão Desenvolvimento Intersix Technologies S.A. SP: (55 11 3803-9300) RJ: (55 21 3852-3240) www.intersix.com.br Your Security is our Business
Pedro Lamarão wrote:
Beman Dawes escreveu:
I've put a fair amount of thought into this proposal, and have run some Subversion simulations to make sure it works smoothly.
What do others think?
Here:
"Formal releases occur on a regular schedule. The formal release procedure is simply to package up the last tagged revision of stable, publish release candidates, and decide if there are any issues serious enough to wait for the next stable tag point."
If this process would contemplate a bugfix branches associated with stable tags, and if some backporting fixes effort were made, the people complaining about API stability would be happier.
Separate bug fix release were not envisioned. The known-stable point releases serve as bug fix releases. My intuitive feeling is that Boost library interfaces tend to stay stable for relatively long periods of time, so API stability isn't an issue.
No need to bugfix for ever; maybe just the previous release; or whatever is confortable enough. This should just give more longevity, and a healthier old age, to each Boost release.
The proposed model does not start with a fresh branch for each release. Instead, the stable branch *becomes* the release branch. So there really isn't such a thing as a bug fix branch that has to be maintained. Thanks, --Beman
Pedro Lamarão <pedro.lamarao <at> intersix.com.br> writes: [...]
Beman Dawes escreveu:
"Formal releases occur on a regular schedule. The formal release procedure is simply to package up the last tagged revision of stable, publish release candidates, and decide if there are any issues serious enough to wait for the next stable tag point."
If this process would contemplate a bugfix branches associated with stable tags, and if some backporting fixes effort were made, the people complaining about API stability would be happier.
I agree. In my opinion a new branch should be created on STABLE for each formal release. Its main purpose would be to provide an escape should anything go wrong with the formal release, but it would also be available for smaller scale bugfixing and backporting, subject to availability of necessary resources; I'm aware that control should be exercised over what is committed on the formal release branches, especially since these do not have an associated "unstable" branch. People wishing to contribute to a bugfix branch should ensure that a reasonable amount of regression testing is performed before the branch is given a new "stable" tag. Note that this would require a change in the release numbering scheme; a couple of alternatives could be to add a fourth number for the weekly tags or to just use the date in the YYYYMMDD format.
No need to bugfix for ever; maybe just the previous release; or whatever is confortable enough. This should just give more longevity, and a healthier old age, to each Boost release.
Bug fixing should be performed on an as needed/as voluteered basis. Cheers, Nicola Musatti
"Nicola Musatti" <Nicola.Musatti@gmail.com> wrote in message news:loom.20060512T133243-385@post.gmane.org...
Pedro Lamarão <pedro.lamarao <at> intersix.com.br> writes: [...]
Beman Dawes escreveu:
"Formal releases occur on a regular schedule. The formal release procedure is simply to package up the last tagged revision of stable, publish release candidates, and decide if there are any issues serious enough to wait for the next stable tag point."
If this process would contemplate a bugfix branches associated with stable tags, and if some backporting fixes effort were made, the people complaining about API stability would be happier.
I agree. In my opinion a new branch should be created on STABLE for each formal release. Its main purpose would be to provide an escape should anything go wrong with the formal release, but it would also be available for smaller scale bugfixing and backporting, subject to availability of necessary resources; I'm aware that control should be exercised over what is committed on the formal release branches, especially since these do not have an associated "unstable" branch. People wishing to contribute to a bugfix branch should ensure that a reasonable amount of regression testing is performed before the branch is given a new "stable" tag.
With SVN, the distinction between a branch and a tag is blurred. They are both really just (virtual) copies at a given point in time. It is up to us exactly how we want to organize the releases we do. If I understand you correctly, you are pointing out that sometimes we may want an explicit bugfix branch of STABLE rather than just moving on to the next week's STABLE tag point. We can certainly do that if useful. At this point, I'm not sure we want to try to micro-manage those future decisions. Rather, we can just make adjustments as we gain experience.
Note that this would require a change in the release numbering scheme; a couple of alternatives could be to add a fourth number for the weekly tags or to just use the date in the YYYYMMDD format.
I thought of that, but decided to recommend keeping the initial scheme simple and a continuation of the current, familiar numbering scheme. Thanks, --Beman
Beman Dawes wrote: [...]
With SVN, the distinction between a branch and a tag is blurred. They are both really just (virtual) copies at a given point in time. It is up to us exactly how we want to organize the releases we do.
I see.
If I understand you correctly, you are pointing out that sometimes we may want an explicit bugfix branch of STABLE rather than just moving on to the next week's STABLE tag point. We can certainly do that if useful. At this point, I'm not sure we want to try to micro-manage those future decisions. Rather, we can just make adjustments as we gain experience.
This sounds reasonable. While it is unreasonable to waste resources on things that just may be useful, but aren't necessary, I feel it is just as important not to close the way in advance to exceptions to the main strategy. From what you write I see this is not the case, so your proposal is fine with me as it stands now. Cheers, Nicola Musatti
This is on the right track. Not too long ago we had a discussion of this very topic a few months ago. see http://lists.boost.org/Archives/boost/2006/01/99522.php I made specific proposal similar -but different- to what you're doing here. I failed to make a convincing case for it. I let it rest because I knew that sooner or later the case for it would become more obvious. I see that happening now. I confess that I thought the current process would last at least one more release before breaking down so I was wrong about that. Robert Ramey Beman Dawes wrote:
The current approach to getting releases ready is completely broken in my opinion. Each release requires heroic efforts by the release manager, careful attention by many developers, and endless delays until everything is just right.
This is discouraging to developers and, worse yet, important library upgrades and bug fixes are taking far too long to get into user's hands.
The problems with the current release approach are not caused by release managers or developers, but rather by the release system itself. It just doesn't scale up to the number of libraries now in Boost, since every library has to be ready before a release can occur.
These problems will only grow worse as more libraries are added.
I propose changing to a different release model, one based on always maintaining a release-ready stable branch and merging updates for individual libraries into it asynchronously.
A draft proposal is available at http://mysite.verizon.net/beman/release_overview.html.
I've put a fair amount of thought into this proposal, and have run some Subversion simulations to make sure it works smoothly.
What do others think?
--Beman
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Robert Ramey wrote:
This is on the right track.
Not too long ago we had a discussion of this very topic a few months ago.
see http://lists.boost.org/Archives/boost/2006/01/99522.php
I made specific proposal similar -but different- to what you're doing here. I failed to make a convincing case for it. I let it rest because I knew that sooner or later the case for it would become more obvious. I see that happening now. I confess that I thought the current process would last at least one more release before breaking down so I was wrong about that.
I'd forgotten about that discussion, although I suspect your ideas were a subconscious influence on my thinking. I've added an Acknowledgments sections with a reference to your posting. Thanks, --Beman
Beman Dawes <bdawes@acm.org> writes:
A draft proposal is available at http://mysite.verizon.net/beman/release_overview.html.
What do others think?
Looks good to me; I'm all for having a branch that's "release ready" at all times. It is going to be tight getting all the regression tests run on all platforms every week, though. Anthony -- Anthony Williams Software Developer Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk
Anthony Williams wrote:
Beman Dawes <bdawes@acm.org> writes:
A draft proposal is available at http://mysite.verizon.net/beman/release_overview.html.
What do others think?
Looks good to me; I'm all for having a branch that's "release ready" at all times. It is going to be tight getting all the regression tests run on all platforms every week, though.
Yes, agreed. I first considered a longer cycle time, but then decided a week was a much more natural unit. Will there have to be some adjustments to some of the testing? Probably, but I don't see that as a showstopper. Thanks, --Beman
Beman Dawes wrote:
A draft proposal is available at http://mysite.verizon.net/beman/release_overview.html.
I've put a fair amount of thought into this proposal, and have run some Subversion simulations to make sure it works smoothly.
I like it for the most. A thing that is missing is how to break the stable version when you do want to break it. For example, often when libararies are redesigned, they give up some compilers (Eg. spirit). Sometimes porting can really make a developer feel worn-out. As a concrete example, what happens when I commit the new version of the range library. Can I simply mark some of the compilers as not supported to get it into the stable-branch, or do I have to wait forever to get it from trunk to stable? Also, what happens if several libraries depend on your library in trunk, but can't work with the dependency found in stable? But the version in trunk is not ready to go to stable and so this will stall all libraries that depend on that library? -Thorsten
Thorsten Ottosen escreveu:
As a concrete example, what happens when I commit the new version of the range library. Can I simply mark some of the compilers as not supported to get it into the stable-branch, or do I have to wait forever to get it from trunk to stable?
Your question is answered in the document: "If and only if trunk changes for a library show no unexpected failures on any required compiler/platform, the developer may merge those changes into stable. If the merge causes any unexpected failures whatsoever, the changes must be reverted immediately." Later: "An unexpected failure is any test that fails and is not marked up in status/explicit-failures-markup.xml as an expected failure." If a library don't support a compiler, then all tests can be "expected failures", and the criteria for a marge is met.
Also, what happens if several libraries depend on your library in trunk, but can't work with the dependency found in stable? But the version in trunk is not ready to go to stable and so this will stall all libraries that depend on that library?
This answer is also in the document, implied in the following paragraph: "Problems with one library do not delay release of other libraries. Although release of an update for a particular library may be delayed by a dependency on another library, an upgrade for given library is never delayed by a wait for a non-dependency library." Yes, dependant libraries wait for dependencies to go in. This point should be made more explicit, maybe in a separate "disadvantages" section. This is a very _sound_ proposal. -- Pedro Lamarão Desenvolvimento Intersix Technologies S.A. SP: (55 11 3803-9300) RJ: (55 21 3852-3240) www.intersix.com.br Your Security is our Business
Thorsten Ottosen wrote:
Beman Dawes wrote:
A draft proposal is available at http://mysite.verizon.net/beman/release_overview.html.
I've put a fair amount of thought into this proposal, and have run some Subversion simulations to make sure it works smoothly.
I like it for the most. A thing that is missing is how to break the stable version when you do want to break it.
For example, often when libararies are redesigned, they give up some compilers (Eg. spirit). Sometimes porting can really make a developer feel worn-out.
As a concrete example, what happens when I commit the new version of the range library. Can I simply mark some of the compilers as not supported to get it into the stable-branch, or do I have to wait forever to get it from trunk to stable?
Just markup the failure as expected. I've added a note to make that clearer.
Also, what happens if several libraries depend on your library in trunk, but can't work with the dependency found in stable?
You have to wait for the other libraries to be merged to stable.
But the version in trunk is not ready to go to stable and so this will stall all libraries that depend on that library?
Yes. A good argument to only depend on features of Boost libraries that are in stable. Thanks, --Beman
Beman Dawes wrote:
Thorsten Ottosen wrote:
Also, what happens if several libraries depend on your library in trunk, but can't work with the dependency found in stable?
You have to wait for the other libraries to be merged to stable.
I think I need to explain this better: I upgrade library A in trunk s.t. it is no longer compatible with library B (which depends on A) in either trunk nor table. Since A don't work with B.stable, I can't commit A to stable. Since B.trunk can be made to work with A, B.trunk can be made to work. However, as soon as one tries to commit B.trunk to stable, it can't because it won't work with A.stable. Basically we need to commit A and B at the same time. Neither can go alone. Does it make sense? Thorsten
"Thorsten Ottosen" <thorsten.ottosen@dezide.com> wrote in message news:4463A34E.1060400@dezide.com...
Beman Dawes wrote:
Thorsten Ottosen wrote:
Also, what happens if several libraries depend on your library in trunk, but can't work with the dependency found in stable?
You have to wait for the other libraries to be merged to stable.
I think I need to explain this better:
I upgrade library A in trunk s.t. it is no longer compatible with library B (which depends on A) in either trunk nor table.
Since A don't work with B.stable, I can't commit A to stable. Since B.trunk can be made to work with A, B.trunk can be made to work. However, as soon as one tries to commit B.trunk to stable, it can't because it won't work with A.stable.
Basically we need to commit A and B at the same time. Neither can go alone.
Does it make sense?
Yes. The upgrade to A is a breaking change that affects other libraries. So even though the new version of A works well and is itself stable, it should not be merged to STABLE until all other libraries that depend on it are stable. Then all of the libraries involved should be merged into STABLE at the same time. I've updated the doc to make that clearer. Thanks, --Beman
"Beman Dawes" <bdawes@acm.org> wrote in message news:44634D7C.9030108@acm.org...
A draft proposal is available at http://mysite.verizon.net/beman/release_overview.html.
The draft has been updated to reflect comments from Michael Fawcett, Simon Carter, Arkadiy Vertleyb, Pedro Lamarão, Robert Ramey, Anthony Williams, and Thorsten Ottosen. --Beman
Beman, I'll comment on the actual proposal later. Beman Dawes wrote:
I propose changing to a different release model, one based on always maintaining a release-ready stable branch and merging updates for individual libraries into it asynchronously.
Just a quick remark. AFAICS the current release process is slowed down by the switch to boost.build v2 and I am perfectly willing to take the blame for that. The boost.build guys are working hard, some things just take time. Thomas -- Thomas Witt witt@acm.org
Thomas Witt wrote:
Beman,
I'll comment on the actual proposal later.
Beman Dawes wrote:
I propose changing to a different release model, one based on always maintaining a release-ready stable branch and merging updates for individual libraries into it asynchronously.
Just a quick remark. AFAICS the current release process is slowed down by the switch to boost.build v2 and I am perfectly willing to take the blame for that. The boost.build guys are working hard, some things just take time.
Hi Thomas, as I already mention in reply to Jeff, it does not seem that way for me. During V2 switch I've address tens of issues that originally were present. At the same time, regressions in concept_check and mpl, on *all* compilers, that I reported to this list and to you personally are still there. I did suggested to you to setup an issue tracker specifically for listing all issues that must be addressed before release. It would allow anybody to understand the state of release process. Do you still think it's a bad idea? I can create the tracker in 5 mins. - Volodya
On Sat, 13 May 2006 12:38:13 +0400, Vladimir Prus wrote
I did suggested to you to setup an issue tracker specifically for listing all issues that must be addressed before release. It would allow anybody to understand the state of release process.
Do you still think it's a bad idea? I can create the tracker in 5 mins.
This is a great idea. I'd really like to see this, because this would be useful now in organizing and getting the release done ASAP. Posting to the list isn't working... Jeff
"Jeff Garland" <jeff@crystalclearsoftware.com> writes:
On Sat, 13 May 2006 12:38:13 +0400, Vladimir Prus wrote
I did suggested to you to setup an issue tracker specifically for listing all issues that must be addressed before release. It would allow anybody to understand the state of release process.
Do you still think it's a bad idea? I can create the tracker in 5 mins.
This is a great idea. I'd really like to see this, because this would be useful now in organizing and getting the release done ASAP. Posting to the list isn't working...
Why not just create a tracker at SF, Jeff? -- Dave Abrahams Boost Consulting www.boost-consulting.com
"Thomas Witt" <witt@acm.org> wrote in message news:e42uk4$ibl$1@sea.gmane.org...
Beman,
I'll comment on the actual proposal later.
Beman Dawes wrote:
I propose changing to a different release model, one based on always maintaining a release-ready stable branch and merging updates for individual libraries into it asynchronously.
Just a quick remark. AFAICS the current release process is slowed down by the switch to boost.build v2 and I am perfectly willing to take the blame for that. The boost.build guys are working hard, some things just take time.
The proposal to radically alter the release approach is motivated by a general need to scale up the release process as Boost grows, and to decouple releases for unrelated libraries. It isn't a particular problem with 1.34, or any particular release. So please don't take the proposal as a criticism of any release or the people working on any release. --Beman
Beman, Beman Dawes wrote:
"Thomas Witt" <witt@acm.org> wrote in message news:e42uk4$ibl$1@sea.gmane.org...
The proposal to radically alter the release approach is motivated by a general need to scale up the release process as Boost grows, and to decouple releases for unrelated libraries.
It isn't a particular problem with 1.34, or any particular release. So please don't take the proposal as a criticism of any release or the people working on any release.
I didn't take it personally and if I haven't made that clear my intent wasn't to criticize or single out boost.build either. I was just trying to point out that the proposal does not address one of the main issues in this release. IIUC that wasn't goal of the proposal, I just wanted people to understand that there are other issues. Thomas PS: For a more general comment see my reply to Jeff -- Thomas Witt witt@acm.org
Beman Dawes <bdawes@acm.org> writes:
A draft proposal is available at http://mysite.verizon.net/beman/release_overview.html.
I've put a fair amount of thought into this proposal, and have run some Subversion simulations to make sure it works smoothly.
What do others think?
Mostly great. I'm concerned about these time slots. They don't seem necessary in principle since subversion has atomic commits, and they seem like they could introduce spurious lock contention on the repository. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:ud5eiorfd.fsf@boost-consulting.com...
Beman Dawes <bdawes@acm.org> writes:
A draft proposal is available at http://mysite.verizon.net/beman/release_overview.html.
I've put a fair amount of thought into this proposal, and have run some Subversion simulations to make sure it works smoothly.
What do others think?
Mostly great. I'm concerned about these time slots. They don't seem necessary in principle since subversion has atomic commits, and they seem like they could introduce spurious lock contention on the repository.
Point taken, although I'm not sure how serious a problem it is. If it is a real problem, maybe something link this: Step one: developers during the week merge into a "next" branch of stable. Step two: once a cycle (tentatively weekly), a single merge of the "next" branch into stable head is done. --Beman
"Beman Dawes" <bdawes@acm.org> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:ud5eiorfd.fsf@boost-consulting.com...
Beman Dawes <bdawes@acm.org> writes:
A draft proposal is available at http://mysite.verizon.net/beman/release_overview.html.
I've put a fair amount of thought into this proposal, and have run some Subversion simulations to make sure it works smoothly.
What do others think?
Mostly great. I'm concerned about these time slots. They don't seem necessary in principle since subversion has atomic commits, and they seem like they could introduce spurious lock contention on the repository.
Point taken, although I'm not sure how serious a problem it is.
If it is a real problem, maybe something link this:
Step one: developers during the week merge into a "next" branch of stable. Step two: once a cycle (tentatively weekly), a single merge of the "next" branch into stable head is done.
I still don't understand why we'd bother with either approach. What problem are you solving. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On 5/17/06, David Abrahams <dave@boost-consulting.com> wrote:
"Beman Dawes" <bdawes@acm.org> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message
Mostly great. I'm concerned about these time slots. They don't seem necessary in principle since subversion has atomic commits, and they seem like they could introduce spurious lock contention on the repository.
Point taken, although I'm not sure how serious a problem it is.
If it is a real problem, maybe something link this:
Step one: developers during the week merge into a "next" branch of stable. Step two: once a cycle (tentatively weekly), a single merge of the "next" branch into stable head is done.
I still don't understand why we'd bother with either approach. What problem are you solving.
How long do regression tests take to run? My understanding was that they took a while. If a library maintainer is allowed to merge into stable while a regression test is taking place, does the stable branch remain untested until the regression testing takes place again (two days later), or does it kick off another regression test? I'm unclear how the flow of events take place if you don't lock for regression testing. --Michael Fawcett
"Michael Fawcett" <michael.fawcett@gmail.com> writes:
How long do regression tests take to run? My understanding was that they took a while.
Depends on the site, of course, but yes, "a while" is not inaccurate.
If a library maintainer is allowed to merge into stable while a regression test is taking place, does the stable branch remain untested until the regression testing takes place again (two days later), or does it kick off another regression test?
We get to decide, I suppose. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes:
Beman Dawes <bdawes@acm.org> writes:
A draft proposal is available at http://mysite.verizon.net/beman/release_overview.html.
I've put a fair amount of thought into this proposal, and have run some Subversion simulations to make sure it works smoothly.
What do others think?
Mostly great. I'm concerned about these time slots. They don't seem necessary in principle since subversion has atomic commits, and they seem like they could introduce spurious lock contention on the repository.
Any comment here? Why the time slots? -- Dave Abrahams Boost Consulting www.boost-consulting.com
Beman Dawes wrote:
The current approach to getting releases ready is completely broken in my opinion. Each release requires heroic efforts by the release manager, careful attention by many developers, and endless delays until everything is just right.
No doubt that the process is broken. I will say though, part of the problem has always been nicely waiting for fixes to be made. Releases could trivially be made by reverting any library with regressions to the version in the previous build. This is similar to what you are proposing, but would be more on the shoulders of the release manager to be ruthless about meeting the deadlines. The current release, for example, would be progressing much faster if we just took the obvious position: v2 build system isn't stable enough, revert to v1 and move on. v2 will be in the next release.
This is discouraging to developers and, worse yet, important library upgrades and bug fixes are taking far too long to get into user's hands.
The problems with the current release approach are not caused by release managers or developers, but rather by the release system itself. It just doesn't scale up to the number of libraries now in Boost, since every library has to be ready before a release can occur.
Again, it's mostly because the release managers are too nice. I'll volunteer to be the next release manager, I'll set a date, and I'll pretty much assure you that it will go out on or about that date because I'd cut any change off that wasn't ready. One really good thing about your proposal is that it builds in the fix it or you're reverted expectation that has been lacking for so long.
These problems will only grow worse as more libraries are added.
I propose changing to a different release model, one based on always maintaining a release-ready stable branch and merging updates for individual libraries into it asynchronously.
A draft proposal is available at http://mysite.verizon.net/beman/release_overview.html.
I've put a fair amount of thought into this proposal, and have run some Subversion simulations to make sure it works smoothly.
What do others think?
In general I like the direction. A couple concerns though: 1) This does mean additional work for developers since all changes will require merges. So this better be really easy to do in SVN for the trivial merges for an entire library. I still don't use SVN on a daily basis, so it is hard for me to evaluate how much work merging will require. Overall, however, it will be worth a little extra work to make the release process actually work again... I also wonder if there should be exceptions to this policy. For example, a documentation update or example code not compiled as part of regression test update. Putting these on the trunk will not provide any feedback anyway. The only danger is that if you allow these exceptions someone might get sloppy. 2) The dynamics of past releases have shown over and over that as good as the regression system is unexpected things show up. So we either need to tag a point where minor changes can be made to a release stable point or freeze major changes on stable for a beta period while beta-testers go one last step and test the packaged release. This is mostly to avoid having to redo release notes, version numbers and other work associated with the release. 3) Some core libraries need to be mercilessly reverted on the trunk as well as on stable. There is a core set of libraries that cause major issues when they don't work. type traits, config, and test come to mind. If these libraries are unstable on the trunk they prevent other developers from validating and moving their code to stable. Thus developers of these libraries will need to be held to a higher standard than developers of other libraries. They need to revert changes on the trunk after some pre-defined period (48 hours maybe) if they can't fix a build issue that is breaking lots of other libraries. 4) I suggest that the set of compilers monitored on the stable branch will only be the group of agreed "supported compilers". If volunteers want to add a new compiler to the supported set (say some new version of the Sun compiler) they must demonstrate that a previous stable build of Boost passes all libraries with no unmarked failures. It is up to these volunteers to work with developers to achieve this state using the trunk. Thx for doing this Beman -- it's something that really needs to be tackled. Jeff ----- Minor wording nits: * Regression tests are run daily on both trunk and stable. Testers coordinate via the boost-test mailing list to ensure that both truck and ^^^^^ Note well: Reverting is a safety-value only. Developers must never ^^^^^^^^^^^^
Jeff Garland wrote:
Beman Dawes wrote:
The current approach to getting releases ready is completely broken in my opinion. Each release requires heroic efforts by the release manager, careful attention by many developers, and endless delays until everything is just right.
No doubt that the process is broken. I will say though, part of the problem has always been nicely waiting for fixes to be made. Releases could trivially be made by reverting any library with regressions to the version in the previous build. This is similar to what you are proposing, but would be more on the shoulders of the release manager to be ruthless about meeting the deadlines. The current release, for example, would be progressing much faster if we just took the obvious position: v2 build system isn't stable enough, revert to v1 and move on. v2 will be in the next release.
Huh? Sorry, this is FUD. Though V2 initially caused quite a number of issues on it's own, they were fixed pretty quickly, and the remaining issues can be knocked down quickly too. The problem is that I don't see any effort to close other issues. Let me get specific: - There's date_time failures with FelipeAlmeida and Bronek_office runners, which use V1. How V2 prevents you from investigating them? - The concept_check and mpl libraries fail across *all* toolsets. I've reported this here, twice, and nothing is still done.
The problems with the current release approach are not caused by release managers or developers, but rather by the release system itself. It just doesn't scale up to the number of libraries now in Boost, since every library has to be ready before a release can occur.
Again, it's mostly because the release managers are too nice. I'll volunteer to be the next release manager, I'll set a date, and I'll pretty much assure you that it will go out on or about that date because I'd cut any change off that wasn't ready.
How about reverting date_time to the version that was shipped with 1.33, right now, on the grounds of there being test failures? Sorry if that sounds rush, but I simply don't think that "revert war" on mainline is a best way to handle anything. The "stable branch" idea from Beman, on the other hand, sounds quite feasible. It might be even better if merges to stable branch are done by release manager only, so that he gets full control of what goes to release. - Volodya
Vladimir Prus <ghost@cs.msu.su> writes:
The problem is that I don't see any effort to close other issues. Let me get specific:
- There's date_time failures with FelipeAlmeida and Bronek_office runners, which use V1. How V2 prevents you from investigating them? - The concept_check and mpl libraries fail across *all* toolsets. I've reported this here, twice, and nothing is still done.
I didn't notice a report recently about concept_check. I thought I checked in fixes for the problems we were seeing. Hmm, maybe the CVS outage kept things from going in... lemme check. Um, despite SF site status saying that CVS is up, I can't reach the server through ssh: $ ssh -v david_abrahams@cvs.sourceforge.net OpenSSH_4.3p2, OpenSSL 0.9.8a 11 Oct 2005 debug1: Reading configuration data /home/dave/.ssh/config debug1: Connecting to cvs.sourceforge.net [66.35.250.207] port 22. debug1: connect to address 66.35.250.207 port 22: Connection reset by peer ssh: connect to host cvs.sourceforge.net port 22: Connection reset by peer So I may well be sitting on fixes that I can't check in. Can't tell of course, because with CVS you can't do a diff unless you can reach the server. I've submitted a support request at SF, but in principle they don't check those except on weekdays... :(
Sorry if that sounds rush, but I simply don't think that "revert war" on mainline is a best way to handle anything.
Agree
The "stable branch" idea from Beman, on the other hand, sounds quite feasible. It might be even better if merges to stable branch are done by release manager only, so that he gets full control of what goes to release.
Sounds good to me. -- Dave Abrahams Boost Consulting www.boost-consulting.com
--- David Abrahams <dave@boost-consulting.com> wrote:
I didn't notice a report recently about concept_check. I thought I checked in fixes for the problems we were seeing. Hmm, maybe the CVS outage kept things from going in... lemme check.
Um, despite SF site status saying that CVS is up, I can't reach the server through ssh:
$ ssh -v david_abrahams@cvs.sourceforge.net OpenSSH_4.3p2, OpenSSL 0.9.8a 11 Oct 2005 debug1: Reading configuration data /home/dave/.ssh/config debug1: Connecting to cvs.sourceforge.net [66.35.250.207] port 22. debug1: connect to address 66.35.250.207 port 22: Connection reset by peer ssh: connect to host cvs.sourceforge.net port 22: Connection reset by peer
So I may well be sitting on fixes that I can't check in. Can't tell of course, because with CVS you can't do a diff unless you can reach the server. I've submitted a support request at SF, but in principle they don't check those except on weekdays... :(
The boost CVS is indeed active since Friday, but you have to patch all your CVS Root files since the server address has changed, e.g. first create a file "Root" somewhere, e.g. in your home directory, with just one line: abrahams@boost.cvs.sourceforge.net:/cvsroot/boost Then cd into boost and run: find . -name Root -exec cp $HOME/Root {} \; Unfortunately there is another problem: cvs update: [06:07:02] waiting for vawjr's lock in /cvsroot/boost/boost/libs/regex/test/c_compiler_checks It started Friday afternoon. I think the only way to remove the stale lock is to open a SF support request. Cheers, Ralf __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Ralf W. Grosse-Kunstleve wrote:
The boost CVS is indeed active since Friday, but you have to patch all your CVS Root files since the server address has changed
If you have wincvs, and the TCL shell active in it, there's a macro that will also do this for you "Macro, CVS, Change CVSROOT".
Unfortunately there is another problem:
cvs update: [06:07:02] waiting for vawjr's lock in /cvsroot/boost/boost/libs/regex/test/c_compiler_checks
It started Friday afternoon. I think the only way to remove the stale lock is to open a SF support request.
I already did that <http://sourceforge.net/tracker/?func=detail&aid=1488367&group_id=1&atid=200001>. -- -- 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
"Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> writes:
--- David Abrahams <dave@boost-consulting.com> wrote:
I didn't notice a report recently about concept_check. I thought I checked in fixes for the problems we were seeing. Hmm, maybe the CVS outage kept things from going in... lemme check.
Um, despite SF site status saying that CVS is up, I can't reach the server through ssh:
$ ssh -v david_abrahams@cvs.sourceforge.net OpenSSH_4.3p2, OpenSSL 0.9.8a 11 Oct 2005 debug1: Reading configuration data /home/dave/.ssh/config debug1: Connecting to cvs.sourceforge.net [66.35.250.207] port 22. debug1: connect to address 66.35.250.207 port 22: Connection reset by peer ssh: connect to host cvs.sourceforge.net port 22: Connection reset by peer
So I may well be sitting on fixes that I can't check in. Can't tell of course, because with CVS you can't do a diff unless you can reach the server. I've submitted a support request at SF, but in principle they don't check those except on weekdays... :(
The boost CVS is indeed active since Friday, but you have to patch all your CVS Root files since the server address has changed, e.g. first create a file "Root" somewhere, e.g. in your home directory, with just one line:
abrahams@boost.cvs.sourceforge.net:/cvsroot/boost
Oh, that's just intolerable. Did they even announce the change??! Wasn't it just a few years ago that that very address became unusable and we were forced to switch to plain cvs.sourceforge.net? Get me offa SourceForge, please! -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes:
"Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> writes:
The boost CVS is indeed active since Friday, but you have to patch all your CVS Root files since the server address has changed, e.g. first create a file "Root" somewhere, e.g. in your home directory, with just one line:
abrahams@boost.cvs.sourceforge.net:/cvsroot/boost
Oh, that's just intolerable. Did they even announce the change??! Wasn't it just a few years ago that that very address became unusable and we were forced to switch to plain cvs.sourceforge.net?
Yes, they announced the change, but only last week. Anthony -- Anthony Williams Software Developer Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk
David Abrahams wrote:
abrahams@boost.cvs.sourceforge.net:/cvsroot/boost
Oh, that's just intolerable. Did they even announce the change??!
They did, to project admins, last week (11/5). FWIW, there are tools to recursively adjust CVS/ metadata, though that should be easy enough to script by hand. Regards, Stefan
Stefan Seefeld <seefeld@sympatico.ca> writes:
David Abrahams wrote:
abrahams@boost.cvs.sourceforge.net:/cvsroot/boost
Oh, that's just intolerable. Did they even announce the change??!
They did, to project admins, last week (11/5).
FWIW, there are tools to recursively adjust CVS/ metadata, though that should be easy enough to script by hand.
find /projects/boost-cvs -name Root -exec sed -i -e \ s/cvs.sourceforge.net/boost.cvs.sourceforge.net/ \{} \; It took a few minutes to run on my box; not a big deal. Anthony -- Anthony Williams Software Developer Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk
Stefan Seefeld <seefeld@sympatico.ca> writes:
David Abrahams wrote:
abrahams@boost.cvs.sourceforge.net:/cvsroot/boost
Oh, that's just intolerable. Did they even announce the change??!
They did, to project admins, last week (11/5).
That would be me, among others. I don't recall ever seeing such an announcement. If I had seen it, I'd have posted it here.
FWIW, there are tools to recursively adjust CVS/ metadata, though that should be easy enough to script by hand.
Yeah, easy enough, especially with Ralf's helpful formula. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes:
- There's date_time failures with FelipeAlmeida and Bronek_office runners, which use V1. How V2 prevents you from investigating them? - The concept_check and mpl libraries fail across *all* toolsets. I've reported this here, twice, and nothing is still done.
I didn't notice a report recently about concept_check. I thought I checked in fixes for the problems we were seeing. Hmm, maybe the CVS outage kept things from going in... lemme check.
Oh, I wasn't thinking. All my recent changes to concept_check are on the trunk. Jeremy created this test, which IIUC just shows how broken every standard library implementation on the planet is. Jeremy, I think the chips are down and you need to decide what to do about this. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Vladimir Prus wrote:
Jeff Garland wrote:
Beman Dawes wrote:
The current approach to getting releases ready is completely broken in my opinion. Each release requires heroic efforts by the release manager, careful attention by many developers, and endless delays until everything is just right. No doubt that the process is broken. I will say though, part of the problem has always been nicely waiting for fixes to be made. Releases could trivially be made by reverting any library with regressions to the version in the previous build. This is similar to what you are proposing, but would be more on the shoulders of the release manager to be ruthless about meeting the deadlines. The current release, for example, would be progressing much faster if we just took the obvious position: v2 build system isn't stable enough, revert to v1 and move on. v2 will be in the next release.
Huh? Sorry, this is FUD. Though V2 initially caused quite a number of issues on it's own, they were fixed pretty quickly, and the remaining issues can be knocked down quickly too.
The problem is that I don't see any effort to close other issues. Let me get specific:
- There's date_time failures with FelipeAlmeida and Bronek_office runners, which use V1. How V2 prevents you from investigating them? - The concept_check and mpl libraries fail across *all* toolsets. I've reported this here, twice, and nothing is still done.
The problems with the current release approach are not caused by release managers or developers, but rather by the release system itself. It just doesn't scale up to the number of libraries now in Boost, since every library has to be ready before a release can occur. Again, it's mostly because the release managers are too nice. I'll volunteer to be the next release manager, I'll set a date, and I'll pretty much assure you that it will go out on or about that date because I'd cut any change off that wasn't ready.
How about reverting date_time to the version that was shipped with 1.33, right now, on the grounds of there being test failures?
Sorry if that sounds rush, but I simply don't think that "revert war" on mainline is a best way to handle anything.
The "stable branch" idea from Beman, on the other hand, sounds quite feasible. It might be even better if merges to stable branch are done by release manager only, so that he gets full control of what goes to release.
The whole point of Beman's proposal is against this last statement. The point is that each library developer should be responsible for getting their library into the stable branch and maintaining that stability at all times. If a library is put into the stable branch with some change which breaks another library, it needs to be backed out until the appropriate libraries are coordinated to work together at the stable branch level. The release manager is then freed to set the appropriate dates and get out the release.
On Sat, 13 May 2006 12:34:41 +0400, Vladimir Prus wrote
Jeff Garland wrote:
Huh? Sorry, this is FUD. Though V2 initially caused quite a number of issues on it's own, they were fixed pretty quickly, and the remaining issues can be knocked down quickly too.
Hi Vladimir - Please, don't get upset -- I'm not trying to single you out -- there's plenty of good reasons for the release delay I'm sure. And I'm sorry, you're right I shouldn't have used an example I don't really have first hand knowledge of -- I haven't paid attention enough to know if V2 is really stalling the current release. Only Thomas can say.
The problem is that I don't see any effort to close other issues. Let me get specific:
- There's date_time failures with FelipeAlmeida and Bronek_office runners, which use V1. How V2 prevents you from investigating them?
Nothing at all. I've been a bit busy so I haven't looked lately and Doug's failure nag seems to have gone away. Of course with no changes in date-time for a month and barely any since the last release it's probably a problem elsewhere, but who knows. I'll try to look today. Of course even if all the regressions were fixed today, someone would realize we need to run the license checker and that would spiral us into another week of fixing, etc, etc.
- The concept_check and mpl libraries fail across *all* toolsets. I've reported this here, twice, and nothing is still done.
Yep.
How about reverting date_time to the version that was shipped with 1.33, right now, on the grounds of there being test failures?
I'd be fine with that if the build manager felt it was necessary to get the release done. I wouldn't make the suggestion if I wasn't willing to have it applied to myself.
Sorry if that sounds rush, but I simply don't think that "revert war" on mainline is a best way to handle anything.
Sure it would. It would change the process in a way that would stop the endless delays and waiting for everything to be fixed. Since the process would be much faster there could be more releases and the fact that date_time or anything else was reverted wouldn't be such a big deal. Again, I'm not suggesting this policy for the current release (frankly it's too late), just pointing out an alternative to the current process that I believe would make the process shorter.
The "stable branch" idea from Beman, on the other hand, sounds quite feasible. It might be even better if merges to stable branch are done by release manager only, so that he gets full control of what goes to release.
That sounds vaguely like what I was proposing ;-) As I tried to say, I'm generally a supporter of Beman's proposal because it basically enforces what I'm talking about -- fix it or it's reverted. Until we get serious about enforcing that no one will pay attention. Jeff
Hi, I am just replying to Jeff for convenience as he brings up a few points I like to addressed. Jeff Garland wrote:
On Sat, 13 May 2006 12:34:41 +0400, Vladimir Prus wrote
Jeff Garland wrote:
Huh? Sorry, this is FUD. Though V2 initially caused quite a number of issues on it's own, they were fixed pretty quickly, and the remaining issues can be knocked down quickly too.
Hi Vladimir -
Please, don't get upset -- I'm not trying to single you out -- there's plenty of good reasons for the release delay I'm sure. And I'm sorry, you're right I shouldn't have used an example I don't really have first hand knowledge of -- I haven't paid attention enough to know if V2 is really stalling the current release. Only Thomas can say.
Boost.Build is not the only issue that is causing a stall. Though it being basic infrastructure it's part of some chicken and egg issues. I.e. I can't fix unless testing works finding build issues is hindered by other outstanding issues. AFAICS this makes for slow progress. If anybody here is worth to single out it's me for not putting on the screws harder.
Nothing at all. I've been a bit busy so I haven't looked lately and Doug's failure nag seems to have gone away. Of course with no changes in date-time for a month and barely any since the last release it's probably a problem elsewhere, but who knows. I'll try to look today.
The regression results are readily available. Even without the nag I think it's reasonable to assume for developers to check them. I am not pointing that out as an accusation but to show that we all work under certain time constraints and that they seem to make impossible what otherwise might be reasonably expected. The reason for the nag to be still inactive is that I was not convinced that not a significant part of the nagging is about testing/build issues, I need to review this decision given the current situation. I did not want people to ignore it for a low signal to noise ratio.
Of course even if all the regressions were fixed today, someone would realize we need to run the license checker and that would spiral us into another week of fixing, etc, etc.
Yes.
Sure it would. It would change the process in a way that would stop the endless delays and waiting for everything to be fixed. Since the process would be much faster there could be more releases and the fact that date_time or anything else was reverted wouldn't be such a big deal. Again, I'm not suggesting this policy for the current release (frankly it's too late), just pointing out an alternative to the current process that I believe would make the process shorter.
I've been giving this some thought and frankly I am not so optimistic. The whole idea of stability is based on reverting to a known stable state. I think this idea is flawed in that we are operating in an ever changing environment. If you looked at the regression table few entries are of the what used to work is now broken variety. Compiler and OS changes are issues that can't be dealt with by reverting. Library interdependencies are another issue. Let's say lib A uses some undocumented feature/corner-case of lib B what happens if B is upgraded and breaks A? Who is at fault who is responsible, who finds out? I think the biggest potential in improving things is to better handle change. The biggest issue here is infrastructure to me. Somebody already mentioned testing resources turnaround times and compiler availability. As I've learned the hard way the supporting infrastructure for boost is huge and there are not always clear responsibilities. Given this the reliability is just insufficient. Most people here are part time boosters they just don't have the time to learn all the intricate details of the system, so every failure is a stumbling block. AFAICS the problem starts at the sf level. We have seen way to many outages/breaking changes recently. As an example regression testing looks broken due to their server renaming. In my opinion being able to run the nagging script continuously would go a long way and this goal does not even interfere with the "stable branch" idea but is a prerequisite AFAICS.
That sounds vaguely like what I was proposing ;-) As I tried to say, I'm generally a supporter of Beman's proposal because it basically enforces what I'm talking about -- fix it or it's reverted. Until we get serious about enforcing that no one will pay attention.
In general I agree, I just don't think it (alone) fixes the problem. Thomas -- Thomas Witt witt@acm.org
participants (19)
-
Anthony Williams -
Arkadiy Vertleyb -
Beman Dawes -
David Abrahams -
Edward Diener -
Jeff Garland -
Kenneth Porter -
Michael Fawcett -
Nicola Musatti -
Pedro Lamarão -
Ralf W. Grosse-Kunstleve -
Rene Rivera -
Robert Ramey -
Russell Hind -
Simon Carter -
Stefan Seefeld -
Thomas Witt -
Thorsten Ottosen -
Vladimir Prus