If memory serves me right, Ben Reser wrote:
> Now you guys are just throwing out ideas without really thinking about
> how the release process works and it's turned into "How can I change the
> process."
(Picking a random message with the word "process" in it to reply to.)
First, I want to thank all of the Subversion developers for a great
product. I really admire your quality, professionalism, and attention
to detail.
Commentary from an outsider looking in: This discussion reminds me a
some problems I've seen first-hand as a former member of FreeBSD's
release engineering team. Basically, doing release engineering using
publically-visible mechanisms (in our case, CVS and FTP mirrors)
introduces a few pitfalls, some of which you have seen yourselves.
Here's a few lessons we learned, perhaps they might be useful in some
way here.
We had two problems in this general area: One is that we needed to make
tags in CVS (in order to generate release images) but we didn't
necessarily want people using these tags as authoritatively defining the
release Until We Said So. (We occasionally needed to tweak the tag for
last-minute build problems, version strings that didn't get bumped
correctly, and so on.) Over the years we've learned to announce tagging
loudly on relevant mailing lists (along with appropriate disclaimers
that tags can change). This generally works pretty well, although every
release cycle there's one or two people who somehow miss this and get
confused. While annoying, I think this is acceptable.
The other problem (which may or may not be applicable here) is that the
process of pushing out ISOs, etc. to our mirror sites in advance of a
release announcement is fairly "public" and visible. Frequently,
someone will "scoop" us by noting on Slashdot or other forum that "the
new ISOs are out!" before we're ready for an official announcement. For
quite a long time we objected vigorously on the grounds that "we might
need to recall the release before we announce it". We had some fairly
elaborate schemes for munging file permissions of files on the mirrors
too. After awhile, we realized this was like trying to squeeze the
toothpaste back in the tube, and we just came to the conclusion that we
just need to wrap up all of the testing before releasing the
distribution to the mirrors.
Something that I think helped users and developers alike to orient
themselves was to post our release engineering processes and TODO list
(as you have done), and also our current schedule. Basically this gave
people the context to interpret various events they were seeing.
Keeping this information current is important.
More info on FreeBSD release engineering can be found at:
http://www.freebsd.org/releng/
Hope this is helpful.
Best,
Bruce.
Received on Mon Apr 4 18:09:13 2005