Boost logo

Boost :

From: Nicola Musatti (Nicola.Musatti_at_[hidden])
Date: 2007-06-12 06:13:29


Robert Ramey <ramey <at> rrsd.com> writes:

>
> Nicola Musatti wrote:
[...]
> > 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.

This is the part we agree on the most :-)

> 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 difference is this part is not taking place on your machine anymore, but on
the regression test machines, otherwise how can you test your changes on primary
platforms you don't have access to?. Access to these machines does require
coordination. In my opinion Beman's and other proposals seem to assume that
there won't be contention of resources here. This is not an assumption I'd draw
from seeing how things are going now.

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

In the light of what I wrote above I don't see how this may be the case.

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

I attribute this situation to the fact that we're performing a sort of
continuous integration in two different environments at the same time (HEAD and
RC branch) most of the time, without a mechanism or procedure to ensure that
breakage is swiftly dealt with.

This in turn is in part induced by the lack of private "repositories" for
development work that isn't yet ready for for integration. In a way we would
probably improve things by just stopping all regression tests on HEAD.

> > 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
> release.
> 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 dependencies" 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.

You seem to assume that libraries cannot improve. The way out of this would be
to share and discuss one's intentions with one's users and then coordinate the
introduction of such changing with the authors of libraries that depend on the
changing interfaces.

I don't think users would appreciate the introduction of duplicated
functionality in family of libraries that, rightly or wrongly, is perceived as a
mostly coherent whole.

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

This is where we disagree. I keep thinking that if self discipline were enough,
there wouldn't be problems right now.

Cheers,
Nicola Musatti


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk