Peter Dimov wrote:
Beman Dawes wrote:
There is a fresh draft of a Boost Development Environment proposal up at http://mysite.verizon.net/beman/development_environment.html
This is a very well thought-out piece. I see one minor problem with it: it depends on additional work from the developers, namely, explicit merge requests. I'm afraid that the principle of least resistance will result in work happening on -devel and -stable stagnating due to lack of merge requests. In a non-volunteer ogranization one will have the authority and means to enforce the procedures and prevent this, but I'm not sure about Boost.
The idea is that merge requests would be something as simple as sending an email to some server which is running a script that automatically checks that all criteria are met and then does the merge. Hopefully that is easy enough that developers won't put off making requests. I personally find the current situation, with very long delays between releases, to be very de-motivating. If releases are done on a more frequent basis, that will be a strong motivation to request merges. But we would certainly need to keep a close watch on the process as it gets going, and make adjustments if developers aren't requesting merges when indicated.
That said, it might be good time for us to radically rethink the structure of Boost and decouple versions from releases. Versions should be per-library, and releases should be a set of versions. This separation ought to be enforced on a directory tree level, as in:
boost/ foo/ foo.hpp bar/ bar.hpp
with nothing else allowed in boost/. A separate compat/ directory would hold the current contents of boost/ (header name-wise), giving people a migration path.
There are additional reasons why we consider at least some change in the Boost directory tree organization. I'll start a separate thread on that topic.
This should probably come with a stricter dependency management approach than the current "none". Each library should list its dependencies, per-library tests should operate on a subtree formed by the dependencies and not on the full boost/ tree, adding an additional dependency should be frowned upon. We might consider introducing "dependency levels" such that a level N library can depend on level N-1 libraries, but not vice versa.
I independently also came to the conclusion that "per-library tests should operate on a subtree formed by the dependencies" and went so far as to write a little program to assign dependency levels to libraries. That has to be done on a library-relative basis so that cycles are dealt with properly. After some more thought, I decided that when a developer requests a test (via the "test on demand" mechanism), it should be possible to request tests on multiple libraries, so that a dependency sub-tree or any portion thereof can be tested. Rather than building dependency lists into the system (which is a fairly heavyweight approach), it might be simpler to give developers a tool to find which libraries are dependent on their library, and then leave it up to the developer how much or little they test against the dependency tree. If a developer who undertests runs the risk that a merge-into-stable request will fail, because merge-into-stable requests fail if they would cause any other library to fail.
With this organization, several releases can proceed in parallel, it being the sole responsibility of the release manager to pick the correct library subset and their versions such that the result is a stable release. More importantly, it allows developers to concentrate on improving their libraries.
Once there one could venture into the direction that packaging a specific release should be the job of the installer and not of the release manager; that is, Boost should package individual library versions, not a monolithic .34.zip. The installer probably ought to also allow upgrading a single library (or adding a new library) should the user so choose.
The larger Boost gets, the more attractive this approach gets. Are we ready for it now? I don't think so. Should we be moving in that direction? Yes! I think we should be thinking in terms of a development environment organization that will support such a parallel development and release mechanism. I'll update development_environment.html accordingly. Thanks, --Beman