Re: [boost] Boost Development Environment proposal

From: Beman Dawes (bdawes_at_[hidden])
Date: 2007-06-04 10:10:27

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