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

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2007-05-05 01:24:27

"Nicola Musatti" <Nicola.Musatti_at_[hidden]> wrote in message 
news:f1gb29$b3s$1_at_sea.gmane.org...
> 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

My proposal doesn't require ANY coordination during boost release. And 
that's the key. Once time has come you collect what's ready at this time, 
combine and release. No testing is done at the time of boost release 
whatsoever. And no waiting.

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

I am still in a dark: what exactly did I give up?

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

No. It will never work from user's prospective IMO. I am using boost xyz. I 
need lib A. Now I am stack and can't upgrade just because library A 
developer has no incentive (or just busy) to build against next version of 
boost.

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

What about those who do need them? They will always be in "one (at least) 
release too late" position.

> By just setting
> apart Serialization regression testing would take half the time, leading

Today serialization. Tomorrow GUI lib, XML parser, HTTP server etc.

> to a much shorter turn around time. The problem is rather that the split
> libraries would need testing resources too.

Yes. Testing. You did not address it. It's completely unclear how do you 
plan to test separated library that depends on some long back release.

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

No. Boost release *has to be consistent*. Otherwise separated component is 
just another third-party library we don't care about.

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

It is. Large number of users tend to stick to single version and use it 
until they jump to another. You propose me to have 10 different versions of 
boost "core" for 10 separated libraries developed at different speed.

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

1. What about long term? Big libraries will continue to appear in boost.
2. How do you decide which library qualify for separation? Does Multi-index 
big-enough or complex enough? How about Date/Time? Or MPL? Regex? Thread? 
One of the biggest is Preprocessor. Does it qualify? On the other hand there 
many small components that other libraries has very little dependency upon. 
Why not separate them?

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

IMO what you proposing is a moving target ;). The examples you provide, just 
prove my point: independent library development is the way to go. The only 
difference is that you propose strange (IMO) combination of existing mess 
and proper way. If we decide that independent development is the way to go, 
why not make it a rule: all libraries are developed independently.

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

Where did you see a moving target in my proposal?

In my makefile I specify: my lib depends on A:abc B:xyz. It can be concrete 
versions for a long time. Once my development is completed, I may switch to 
the LATEST versions of dependent components. With some luck it just 
compiles, otherwise I had to make fixes to comply. Alternatively I may 
decide that I do not want to continue development and don't switch to 
LATEST. In later case my library is not included in next version of boost. 
The only tough case is if library A that depends on LATEST version of 
library B and it was not fixed. Who is at fault here? My proposal is 
postpone library A release. There will be come complications here. But I 
believe they all can be resolved.
   The key advantage above is separation of my own development from 
development of dependent libraries.

Gennadiy