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 ^^^^^^^^^^^^