> I know that there have been lots of changes in .32-dev since .31 was > tagged that have challenged the stability of the current tree. If > we took .32 and made it as close to .31 as we could but with the > *minimum* required changes to make .32, we could be close to a real > beta. (This seems to mimic the APACHE_BEST tag I think was proposed > before my time.)
Actually, that one was during your time. The fact of the matter is that the RM doesn't even need to tag the tree. If they *really* want to test a configuration (set of revisions) on all platforms, then simply checkout HEAD (or whatever) and work within the checked-out tree, avoiding the use of cvs update except for specific file changes. A -dev tarball can be created (with whatever non-version name you want to give it) from the checked-out tree, which can then be tested by people with access to the other platforms. Only after they come back with a +1 is the checked-out tree tagged with the next version number, which impacts only those revisions in that tree and not whatever has happened to HEAD. I mention this every time the release process is argued: it is the responsiblility of the RM to tag a version of the tree that they *think* is stable. How they come to think that will entirely depend on how much time, energy, and resources they can throw at the code *before* it is tagged with a version number. They can do that by managing a checked-out tree or by using a temporary non-version tag to manage a branch of the real tree -- either one is better than tagging the tree with a public version number and them moving that tag around to suit the testers. Once it is tagged with a version number, we need to simply live with the fact that the version number is HISTORY and stop arguing about whether one change or another should be included. BTW, the version number means major.minor.patchlevel After the group spends enough time pounding on a release to call it GA, there is no reason why we cannot take the code and reversion it a 2.1.0 and start treating that as the stable branch. It may be a little confusing to the Linux folks, but we can always skip to 2.2.0 if that makes people happier. Personally, I tend to think that even-numbered releases are less reliable than odd ones, because that has been my experience with the quality of commercial releases. And, personally, I have always hated the stupid alpha/beta/GA distinction. Our release process became constipated on the day that was added. I guess the point is that we shouldn't let the process of tagging the tree interfere with getting a complete-revision-set of the server that is stable enough for a release. There is really no reason (aside from a desire to get three +1 votes) for the RM to need to coordinate with everyone else in the group when a release is ready to be tarballed, nor is there any reason (aside from the release votes) for the RM to include everything on HEAD when they do tag a release version. The only thing that is really necessary is that the final tarball has at least three +1 (and a majority positive) before it is placed in www.apache.org/dist/httpd/. If I were the RM, I'd just work in a tree of relatively stable code and tag the version when I bloody well felt like it was good enough to stake my reputation on as being better than the last version released. No, I don't have time to be an RM right now. OTOH, there is also very little reason why we can't have multiple RMs working in parallel, provided they work with private tag names and let the group decide which tags to promote to an official version. Of course, the real problem is that httpd developers these days just have it too easy. When I was an RM, we had to get up at 4am and walk through snow in our underwear in order get enough carrier pigeons together to distribute a tarball, and then wait a week for enough pigeons to come back alive to count it a release. When it's that hard to do a release, the RM spends a lot more of their own time proofing a tarball before it gets out, and makes a habit of doing a release before there are more than 30 or so changes since the last one, because the probability of that many changes being error-free is approaching zero. I think people just respect the process too much. We are here to maintain and release code -- the process only exists to allow us to get there without killing each other. If it isn't working, determine the part that doesn't work and replace it with something new. The only things that you cannot replace are that code must be committed before it is released and the tarball must be voted on before it is released to the public. ....Roy
