Gennaro Prota wrote:
I'll see how it goes. Manually or not, it's a lot of bookkeeping, and requires time. Since I'm only maintaining dynamic_bitset, I'd expect a few number of interventions, thus I'm probably the wrong guy to complain. But it seems to me that being a Boost developer is going to be a full-time job, really.
In my view, the current system is a huge improvement over the previous one. It wastes a lot less time.
(With the previous repository policy, I could make modifications to a library when I had some spare time, look at the regression reports and forget it.
Now, instead, I have also to wait for the release branch to be open
The release branch should be always open. Once you're happy with all the test results you can merge from the trunk into the "next release", or "rease ready" or whatever its called branch. This gives the effect of developing on a branch (the trunk) that is actually tested by all the testers. Doing on a branch is a lot of excess work and one's stuff doesn't get tested. Its necesary for big changes and new libraries, but its overkill for smaller changes and maintainence. This latest release has been much less painful than previous ones with just a few snafus. And best of all, these snafus are related to small number of specific libraries and tools rather than all over the place. Now attention seems to be getting focused on these issues whereas before they got lost in all the noise. I'll take this opportunity to beat my drum on my proposed improvement to the current proces: I would like to see the testers start with the Release Branch. for each library which has been changed, the related directories are switched to the Trunk and the tests are run. After the test the libraries directories would be switched back to the release branch. This would give the devoloper a clear picture of the result of his changes independent of any other changes made by other developers. Release Testers would retest whenever one or more libraries are merged into the release. Otherwise the procedure would be the same. Robert Ramey