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