Re: [boost] [SVN]Best Practices for developers using SVN

From: Robert Ramey (ramey_at_[hidden])
Date: 2007-08-03 11:46:00

Peter Dimov wrote:

> Consider what happens under the new system, though: the feature is
> blocked because an unrelated library doesn't like it. In the worst
> case,
> unmaintained libraries eventually block all progress on the stable
> branch. This is stable, but as bit more stable than needed.

I don't see this happening at all.

suppose library A is non-maintained and library B is being worked on.
The write of library B makes and tests his improvements using
the published interface of library A and its concluded that
library A doesn't support its published interface in some way.
The one of a couple of things happens.
a) Author of library B contacts author of Library A (say
via bug report and Author of library A fixes it.  The author
of library B either patches his local code or merges in
author A's fix.
b) Author B can't get Author A to fix it and works around it
in some way.

In either case, the whole release process isn't affect - just that
for library B.  Author B will have to find some way of dealing
with it but its an issue between two people and its not holding up
the whole of boost.

The other scenenario.  Author A makes his changes and runs
his tests and things are great.  Unbeknownst to him, he has
changed the public interface, by enforcing a previously
unenforced interface requirement (I did this once) and
of course he doesn't notice as his tests run.  At this
point the changes are merged into the next release and
stuff in other libraries break.  This is not the case where
the maintainer of A is AWOL its just a normal fiasco
which has to be resolved in the usual manner.

So I would refine the proposal somewhat to

a) development and tests are run on a branch (for that library)
b) when its time to merge tests are run next release branch
with the library switched in.  That is, one can run the test
with all of boost BEFORE the library is actually merged in
c) If b passes then the changes are merged into the release and all
tests are run again just to make sure.

This presupposes a test request infrastructure under which one
can specify tests for specific branches and/or all of boost.

> No process can solve the problem of missing/unresponsive maintainers.

I believe that this new process will prevent missing/unresponsive
maintainers from holding up the whole system.

> Another interesting example is adding a new test that exposes an
> existing bug. This test has never passed, but its inclusion is
> prevented by the stability requirement.

The "stability requirement" definition is unclear.  It currently seems
to be "passing all tests" or marking tests as not-passing.

If a new test makes the library better but displays exposes more
errors, then it should be considered an improvement, marked up
and released.

Boost explicitly permits standard conforming code which breaks
with non-conforming compilers.  Failing tests are part of the system
and explicitly addressed through the markup system.

Robert Ramey