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

From: Nicola Musatti (Nicola.Musatti_at_[hidden])
Date: 2007-05-04 18:11:18

Gennadiy Rozental wrote:
> "Nicola Musatti" <Nicola.Musatti_at_[hidden]> wrote in message 
> news:f1frd3$jm8$1_at_sea.gmane.org...
[...]
> Sorry. I was a bit unclear. By independent I mean "independently developed".

OK

>>>> 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?

I'm convinced that one of the problems that lead to 1.34 not being 
released for over a year beyond the original schedule has to do with the 
size and complexity of Boost as a whole and coordinating the personal 
schedules of many developers to reach a single coordinated goal. The one 
advantage of this situation is that each developer has been able to 
react to changes as soon as s/he realized that her/his library was impacted.

By splitting at the library level, but expecting to still issue one 
coherent whole you don't solve the problem, but you give up the one 
advantage. I don't see what your approach would gain us.

>>>> 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.

So? At worst users of specific libraries will be one core release 
behind. They'll have to face the trade off of being able to use the one 
library they need, but having to wait some more time before they can 
adopt some newly introduced core feature. Assuming a more realistic six 
month release cycle for core plus an extra three month for split 
libraries these people would still be much better of than those that 
right now would like to use a library that was reviewed a year ago.

>> 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?

For instance people not using those libraries won't have to wait for 
them to reach stability before a release can be made. By just setting 
apart Serialization regression testing would take half the time, leading 
to a much shorter turn around time. The problem is rather that the split 
libraries would need testing resources too.

>> 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.

Again, this a problem we keep having to face whenever we have to use a 
piece of software that depends on others.

>>> 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.

If the result is a shorter overall cycle than we have now,, this will be 
a non problem.

>> 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?

Again, just as an example, consider splitting off Serialization, Spirit, 
Wave, Python, Mpi. This not just a couple of libs, it's a significant 
portion of the Boost code base, and you still don't have to find out 
which release of Bind goes with which release of Function and so on.

>> 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.

Why do you think so? Spirit is already been developed independently and 
Robert R. clearly intends to do the same with Serialization. I'm sure 
that for them it would be easier to release their libraries against a 
stable release of the rest of Boost than against a moving target.

>> 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.

Keeping up with independent core releases is *less* work than keeping up 
  with a continuously moving target and the reason I'm writing all this 
is because I don't *want* split library authors to be left on their own 
or to go their separate ways. Rather I want Boost to be split into a 
small number of packages and I'm convinced that this would improve 
noticeably the manageability of the whole lot.

Cheers,
Nicola Musatti