Peter Dimov wrote:
Consider what happens under the new system, though: the feature is blocked because an unrelated library doesn't like it. In the worst case, unmaintained libraries eventually block all progress on the stable branch. This is stable, but as bit more stable than needed.
I don't see this happening at all. suppose library A is non-maintained and library B is being worked on. The write of library B makes and tests his improvements using the published interface of library A and its concluded that library A doesn't support its published interface in some way. The one of a couple of things happens. a) Author of library B contacts author of Library A (say via bug report and Author of library A fixes it. The author of library B either patches his local code or merges in author A's fix. b) Author B can't get Author A to fix it and works around it in some way. In either case, the whole release process isn't affect - just that for library B. Author B will have to find some way of dealing with it but its an issue between two people and its not holding up the whole of boost. The other scenenario. Author A makes his changes and runs his tests and things are great. Unbeknownst to him, he has changed the public interface, by enforcing a previously unenforced interface requirement (I did this once) and of course he doesn't notice as his tests run. At this point the changes are merged into the next release and stuff in other libraries break. This is not the case where the maintainer of A is AWOL its just a normal fiasco which has to be resolved in the usual manner. So I would refine the proposal somewhat to a) development and tests are run on a branch (for that library) b) when its time to merge tests are run next release branch with the library switched in. That is, one can run the test with all of boost BEFORE the library is actually merged in c) If b passes then the changes are merged into the release and all tests are run again just to make sure. This presupposes a test request infrastructure under which one can specify tests for specific branches and/or all of boost.
No process can solve the problem of missing/unresponsive maintainers.
I believe that this new process will prevent missing/unresponsive maintainers from holding up the whole system.
Another interesting example is adding a new test that exposes an existing bug. This test has never passed, but its inclusion is prevented by the stability requirement.
The "stability requirement" definition is unclear. It currently seems to be "passing all tests" or marking tests as not-passing. If a new test makes the library better but displays exposes more errors, then it should be considered an improvement, marked up and released. Boost explicitly permits standard conforming code which breaks with non-conforming compilers. Failing tests are part of the system and explicitly addressed through the markup system. Robert Ramey