From new-httpd-return-12764-apmail-new-httpd-archive=apache.org@apache.org Fri Feb 02 23:16:18 2001 Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 4889 invoked by uid 500); 2 Feb 2001 23:16:11 -0000 Mailing-List: contact new-httpd-help@apache.org; run by ezmlm Precedence: bulk Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list new-httpd@apache.org Received: (qmail 4872 invoked from network); 2 Feb 2001 23:16:08 -0000 Date: Fri, 2 Feb 2001 15:13:52 -0500 From: "Roy T. Fielding" To: new-httpd@apache.org Subject: Re: interim release strategy Message-ID: <20010202151352.A816@waka.ebuilt.net> Mail-Followup-To: "Roy T. Fielding" , new-httpd@apache.org References: <20010202022528.A28821@waka.ebuilt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.13-current-20010115i In-Reply-To: ; from rbb@covalent.net on Fri, Feb 02, 2001 at 07:13:41AM -0800 X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N > > 3) nobody talks about releasing something until after it has > > been built and tested; > > I dislike this. IMHO it is a good thing for us to shoot for > releases. Without something to aim for, we could all be going in > different directions. I really want to see everybody aiming at the same > general thing. We are SUPPOSED to be going in different directions! Collaborative open source only works well when each person is working on what they believe to be most important, according to their own personal or company goals, and according to their own personal work schedules and available free time. Some portion of that will also be to the group's benefit, since nobody gets any benefit until the code is released --- it takes at least three happy campers to produce a release. The only time everyone aims at the same thing is when they are being employed to do so or when they have joined a cult. > > 4) nobody freezes the tree -- if it so happens that the tree is > > screwed at the point it was tagged, we just keep going; > > I also dislike this. A code freeze is a useful tool. It allows us to > stabilize quickly, because we are stopping adding new features. At the > very least, we must have feature freeze, and I would hope a thirty minute > freeze for the actual tagging would be acceptable. A code freeze doesn't mean "no new features" -- it means no changes aside from those applied by the RM. And if it were a useful tool, our current release process wouldn't suck. We don't need a freeze, and especially not a feature freeze, because it is extremely rare for the tree to be in a state between features. This doesn't mean that the RM shouldn't tell people that they are about to tag the tree, and it doesn't mean that committers shouldn't use their own good judgement as to when something is committed to the tree. It simply means that we don't need to spend days upon days arguing about when these things should happen, or spend weeks holding our commits just because someone feels that a particular day would be a nice day for a release. Like I said, we can do this because, if it turns out we were unlucky and the tag point does not correspond to a stable tree state, then we just don't release that version. Right now we spend far too much time managing the release process (and yet never producing releases as good as those pre-1.1), while at the same time telling most of the group to stop what they are doing so that we can obey one person's arbitrary release schedule. I think we spent more time in 2000 being in "code freeze" mode than in normal "just do what needs to be done" mode. Fuck that -- we've been doing it for three years now and it doesn't work. The problem is that it makes it nearly impossible for part-time volunteers to work on the code with any degree of satisfaction. The only thing that a code freeze accomplishes in the way of stability is to prevent anyone but the RM from working on the code. Yes, it is somewhat more stable, but at too great a cost. I'd rather take the shotgun approach and determine stability after the fact. > > Right now I'm midway through replacing buildconf. I was planning > > to get it all done this week and tag something this weekend, but > > a long-time friend has decided to surprise me with a visit this > > weekend. Ryan, feel free to tag the tree and build a tarball > > this weekend as soon as you think it should be done (after all, > > it only needs to be better than the last time we tagged). We > > can update the nomenclature later. > > I may tag this weekend, or I may not. I would really like to see more > people comment on this approach, and make sure it is where we want to > go. I am also going to get home tomorrow at around 1:00, so I will most > likely want to spend Saturday with my wife. So if I tag, it will be > Sunday. I wanted to be sure that I wasn't holding you up if you were planning to work on it. Personally, I'd be happy to let anyone with commit access tag the tree whenever they think it builds on all the major platforms. The role of RM was intended to simply coordinate testing and pick up stray patches from non-committers, not to manage the goals of the group. ....Roy