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

From: Robert Ramey (ramey_at_[hidden])
Date: 2007-08-01 18:53:27

Stefan Seefeld wrote:

>> Right, although as a practical matter most developers will want to
>> test against "stable".
>
> What are they testing ? And what (and, more importantly, where) are
> they developing ?

They are testing changes to the libraries they are developing.  They
are depending upon only the last/next released version of boost.

>> So whenever I want to see if the code is working on the non-Windows,
>> I sign onto the web sites, request tests be run, and have the
>> results in a couple of minutes.

I presume that this this "secret sauce" will sometime become available
to other developers?  I don't see it anywhere now.

> For avoidance of doubt: the tests are run on your 'c++0x' branch,
> right ? How many such branches do you expect to coexist ?

approximately one per developer.

> How many people do
> you expect to collaborate on such branches ?

one or two.

> At what frequencies do
> you expect branch-specific testing requests to be issued ?

as needed - depending on how hard one is working it could
be as often as once/day but I would expect 5-10 times for
each major library revision.

> Does the procedure scale ?

very much so.  Instead of testing the whole of boost - whether
anyone needs it or not.  Only one library is tested at time.
Currently, the time to test grows quadraticly.  Number of
libraries x Time to run a test.  The time to run a test grows
with the number of libraries.  Under the new system, testing
will only grow linearly with the number of libraries. as only
the library branch is tested on request.  This is a fundemental
motivation for this system.

> Also, of course, such requests can only be issued for machines
> (platforms) that are readily available, right ?

LOL - this is "secret sauce" which is still secret - at least from me.
I presume it wll be revealed to the "rest of us" when its "ready"

> I think this is where buildbot enters the picture. It allows to set up
> a set of schedulers that control the actual testing, e.g. imposing
> constraints on how often tests may be run. That will help to manage
> the available (and probably rather scarce) resources: build slaves
> for the various platforms.

Something that does this function will be needed but I doubt it will
be as elaborate as you suggest.  But who knows - it seems it's
still being experimented with.

> Right. Again, for avoidance of doubt: do you expect the development
> branch to be created from the stable branch, to make sure a passing
> test on the development branch translates to a passing test on stable
> after a merge. Correct ?

Now you've hit upon the motivation for my original post.  I was under
the impression that the "trunk" would be the last released version.  It
turns out that its not so.  But no matter.  With SVN there is no special
status accorded "trunk" we can just branch off the last release.  The
only think we need is a set of "Best Practices" (or whatever one
wants to call it so we're all in sync.

> I'm asking because this essentially means that stable becomes the only
> reference, throughout boost development. In fact, not only a
> reference,
> but a synchronization point. It becomes the developer's duty to
> backport
> all changes that go into stable from other development effords, making
> sure the tests still pass, before forward-porting the local changes to
> stable.

Halleluhuh - you've got it !!!.

> While I agree this sounds good, it also implies quite a bit of
> additional work for every developer.

Its A LOT LESS work for the developer.  Under the current  (old) system
every time a test failed I would have to investigate whether it was due
to an error new error in my library or some change/error in something
that the library depended up.  It consumed waaaaay too much time.  I gave
up commiting changes except on a very infrequent basis.  Turns out
that the failures still occurred but I knew they weren't mine so I could
ignore them.  Bottom line - testing was a huge waste of time providing
no value to a  library developer.

Don't even start on the effort trying to get a release out when everything
is changing at once.

And scaling.  each boost release with one library added will basically
be a pain in the neck for one developer and maybe the release manager
(though not necessarily).  Now its a pain in the neck for ALL developers
at once.

Robert Ramey