Re: [boost] asio status (was: 1.34 Release Plan)

From: Paul Baxter (pauljbaxter_at_[hidden])
Date: 2006-01-27 14:27:52

> On Jan 26, 2006, at 5:58 AM, Paul Baxter wrote:
>> While on the subject of releases, it has been mooted that perhaps
>> Boost shouldn't be released as one monolithic package and that
>> the problem might be better tackled by a finer grained approach
>> and having a two-tier release management structure.
>> Individual 'modules' are released upwards (and
>> available as versioned outputs) and a main boost release is simply a
>> collection of latest inter-operable set of versioned modules.
>
> The problem with a fine-grained approach is that all of the grains
> have to fit together. We have to manage version dependencies between
> the components (e.g., to deal with breaks in backward compatibility),
> and deal with user problems that arise from mismatched component
> versions. We'd have to push our overly-taxed regression testing
> systems harder to cover various collections of modules.

>
> I'm not completely against the finer-grained approach, but I've seen
> enough problems with it in other projects to cause some concern. Have
> you ever maintained a Linux system using Gentoo? It's nearly
> impossible to duplicate (and, thus, diagnose) errors from one system
> to the next, because nobody has exactly the same set of components.

I'm in complete agreement about Gentoo and boost at too fine a granularity, 
but I had envisaged the process to involve a look at library dependencies 
and try to capture a boost 'core' package and then satellite packages around 
it. Many of the boost libraries depend on a couple of key libraries and then 
are largely independent of the majority of the rest.

You'll never find a completely satisfactory core set of libraries that works 
for everyone, but it also seems wrong to delay a 'core' release because one 
non-core library has a few problems with a couple of compilers. Why not 
release a new core and then when the satellite library is ready it can play 
catchup. A boost 'full' release could occur as such a point where all the 
satellite packages have caught up with the core version and devolves 
responsibility for satellite packages lessening (in theory) the release 
manager's workload.

Of course some 'satellite' packages are going to be dependent on others, so 
there still needs some level of coordination between them but I'd much 
prefer the core to be available as a tested entity even if say a 
serialisation or an asio library still has some final gotchas to sort out.

> Where has the fine-grained approach worked well? How can Boost
> duplicate their model to successfully deploy a more modular Boost?

I'm thinking linux kernel = core, userspace programs = satellites.
Also perhaps larger userspace efforts like KDE that are already managed as 
multiple packages dependent on a core set of headers and functionality.

> How much effort would be involved both in the conversion and in
> maintaining the resulting modular Boost? I could spew more questions,
> but my underlying question is much more broad: While component-
> oriented systems work wonderfully on paper, I've seen far more
> failures than successes, and I'd like to see why we think Boost can
> get itself into the latter category.

I certainly agree with this and accept the caution however I worry that 
boost is becoming like the ACE framework, very well regarded but with a 
steep learning curve and a bit of an 'all or nothing' proposition. That 
applies both to test/release and usage.

If all libraries depended on many others and dependencies really couldn't be 
factored into a core with some satellites, this approach gets blown out the 
water, of course.

Paul