From: Robert Ramey (ramey_at_[hidden])
Date: 2007-06-11 19:27:57
Nicola Musatti wrote:
>> 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.
Again, total disgreement. I run boost serialization tests on my home
machine with bjam. I just move to the serialization/test directory
and invoke a batch file which invokes bjam. There is no reason
that anyone one else couldn't do that on their own machine. The
only "coordination" required is a means to request the test and
return the results. There is no reason this process has to be
"coordinated" with anyone else - except to agree that that
the test is to be run after moving to the proper development
branch. Beman's proposal doesn't detail the mechanism
for requesting a test, and posting results - but I don't see that
that is a big issue. The essential fact is that this testing can
run totally independently of everyone else - in fact that is
exactly what happens when I run a test on my own machine.
I don't have to "coordinate" this with anyone and so far no
one has complained.
> I see a contradiction here: you ask for flexibility, yet you expect a
> much tighter coordination of activities.
I expect LESS coordination of activities. The problems we have now
are due to the fact that each and every library has to be in exactly the
same state -
ready for next release - at the same moment. Beman's proposal only
requires that each library be ready one at a time.
> 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.
Beman's proposal make no mention of dependency management. Implicit in the
proposal are the following dependency "rules"
a) each library is consistent with the state of those in the current
b) library developer's should not break a current interface.
Now b) will create a problem for some developer's. Some just won't
care that their quest for perfection will leave other developer's out
on a limb. No one can change this. No one can enforce a rule that
interfaces can't change. No system of "managing dependcies" can
prevent this. Developer's that do this will find that users
and other developers won't want to depend on their library and
the library will fall into disuse. The best we can do is run the final
test after each library is integrated into the release and reject it
if it breaks its interfaces.
> 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.
The MPL developer shouldn't do that except for very unsual cases.
Generally such changes will be detected when the final test is run
and the requested integration would be denied as in includes interface
> How's that different from what we have now?
Now there are no disencentives to interface breaking changes and
they cause all sorts of havoc.
> How does a similar situation affect the test request queue?
> you stop everything until you and the MPL authors sort things out?
proposed integration of MPL update is denied due to interface breaking
If it is determined that the interface has to be broken, then other
which rely upon will have to choose to change their code or elminate
their dependency on the library.
> 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.
That's whats causing the current difficulty. Working harder at it will
just make it worse.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk