Vladimir Prus wrote:
Jeff Garland 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
Beman Dawes wrote: 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.