Re: [boost] [BoostCon07][testing] Session reminder.

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2007-05-04 14:16:47

"Nicola Musatti" <Nicola.Musatti_at_[hidden]> wrote in message 
news:f1frd3$jm8$1_at_sea.gmane.org...
> Gennadiy Rozental wrote:
> [...]
>>> I believe there are two problems in Gennadiy's proposal: the granularity
>>> is too fine
>>
>> It's natural separation by independent libraries
>
> I might agree if they really were independent, but in many cases they
> are not. On the other hand there are a number of rather large libraries
> that have fewer dependent ones.

Sorry. I was a bit unclear. By independent I mean "independently developed".

>>> and the constraint of releasing Boost in a single whole is going to make
>>> things unnecessarily hard.
>>
>> Which constrain?
>
> I'm under the impression that in your scheme you expect to be able to
> assemble a complete Boost release by choosing the appropriate releases
> of all the component libraries.

Yes. So what is the problem?

>>> A better approach would be to separate from core Boost some of the 
>>> larger
>>> libraries once and for all. I'm thinking of Serialization, Spirit, 
>>> Python,
>>> possibly a few others. In most cases other libraries should not depend 
>>> on
>>> these
>>> (i.e. Preprocessor is not a good candidate). Where dependencies exist 
>>> they
>>> should either be removed or moved to reside within the separate library
>>> (e.g.
>>> serialization support for core libraries should be supplied by
>>> serialization and
>>> not core [as I believe it is now, at least in many cases]).
>>>
>>> These libraries should be developed, tested and released separately,
>>> against the
>>> most recent release of core. It will be up to each library mantainers'
>>> team to
>>> decide whether to "port" one or more released versions of their library 
>>> to
>>> new
>>> releases of Boost Core, while they work on a new major release.
>>
>> 1. This in no way address problem developing and releasing libraries that
>> other depend on. And this is biggest problem IMO
>
> All that is needed is to shift the release date of the split libraries
> some 2-3 months after the release of core, assuming a six month release

What if we want to release "core" every 3 month? But what is more important 
there is independently developed libraries within core.

> cycle. Core developers will take advantage of the more manageable size
> of the library collection they work on, while split libraries'

What advantage? Each developer really care about one's own library size and 
dependencies. Why do you believe that be splitting couple libraries we 
achieve anything?

> developers will gain from the resulting period of Core's guaranteed
> stability.

What stability? Core is stable to 6 month next release library A is updated. 
For 6 month separated library B tested against outdated version and it 
become unusable once next "core" release occurs. It takes another couple 
month to make another release of library B compatible with A, only to become 
invalid again in a month or so when next version of "core" is released.

>> 2. You proposition leads to the separated libraries to be potentially
>> unusable with latest boost release. This is not a good thing IMO.
>
> People that only use core will be able to switch to a new release
> immediately; those who need one or more of the separated libraries will
> have two wait up to three months. On the other hand by reducing Core

And something will always be  missing: either update to separate library or 
new feature from "core" one.

> Boost to a much more manageable size than whole Boost is nice, the
> chances of hitting planned release dates should increase. If you

How splitting couple libs will make it "much more manageable"? And if you 
split let's say 2/3 of libs how is it different from what I propose?

> consider how long people have been waiting for the libraries that were
> introduced/improved in 1.34, not to mention those that are expected for
> 1.35...
>
>> 3. Who make this decision? Which libraries are "core" and which are
>> standalone?
>
> This will have to be agreed upon, considering size, dependencies and
> breadth of applicability.

This will never going to be agreed upon.

> Ideally library authors should offer to split
> off their libraries if they think it reasonable. In a way Robert Ramey
> is already heading in a similar direction with Serialization. I think he
> should be encouraged to do so, but within an agreed upon setup, rather
> than in total independence, so that other authors may benefit from the
> experience gained.

There is no real incentive for a library author to do extra work of keeping 
up with independent "core" releases. In my scheme you can't add "core" 
library release to the boost release until all the libs that depend on 
LATEST version of the library are tested against it. What you propose 
essentially leave every developer of separated libraries on their own. While 
the same time developers of the "core" libraries are still faces with 
current interdependencies problem.

Gennadiy