Re: [boost] Independent Libraries Versioning proposal

From: Nicola Musatti (Nicola.Musatti_at_[hidden])
Date: 2007-06-11 18:15:09

Robert Ramey wrote:
> Nicola Musatti wrote:
[...]

>> On the
>> other hand unless additional resources are found there's little
>> else that can be done, apart from a little rationalization and,
>> certainly, fixing the current tools.
> 
> The resources dedicated to testing would be much less than now so
> more effective testing could be done.  That is this system would test
> only that which would benefit from testing - much, much less that the
>  current approach.

In terms of total usage I agree, but for this to work a much higher 
degree of coordination is required. I don't think it may be achieved 
without a form of tight centralized control.

[...]
>> I still think that what I suggest here: 
>> http://svn.boost.org/trac/boost/wiki/AlternateProcessProposal is
>> close to the minimum change we must apply if we want things to take
>> a different turn in 1.35 .
> 
> I skimmed your document and:
> 
> a) I don't believe that beman's proposal requires changing the
> directory tree structure. b) I don't believe that bemans proposal
> requires a change to SVN.
> 
> But my main object is that it is "top down" in that is imposes more 
> rules and structure on the testing/release procedure.  I think that
> our current problems stem from the same approach.  I think that the
> system has to be designed to permit more flexibility - not less which
> I think is what Beman's proposal does.

I see a contradiction here: you ask for flexibility, yet you expect a 
much tighter coordination of activities. All the proposals I've seen 
either wish for dependency management tools that aren't there or expect 
dependency problems to somehow sort themselves out. Suppose you've made 
some changes, asked and obtained that tests be run on your code, they 
passed and you checked in your code. Then the same goes for, say, MPL, 
but their change breaks your code. How's that different from what we 
have now? How does a similar situation affect the test request queue? Do 
you stop everything until you and the MPL authors sort things out?

In my opinion flexibility stems from the fact that with a much shorter 
release cycle skipping one is not going to be such a big deal, so 
developers will be faced with reasonable alternatives. For that to 
happen each cycle must be managed very rigorously.

Cheers,
Nicola Musatti