On Mon, Jul 18, 2011 at 4:57 AM, Bert Huijben <b...@qqmail.nl> wrote: > > >> -----Original Message----- >> From: Greg Stein [mailto:gst...@gmail.com] >> Sent: zondag 17 juli 2011 12:14 >> To: Hyrum K Wright; dev@subversion.apache.org >> Subject: Re: 1.7.0-beta1 up for testing / signing >> >> On Sun, Jul 17, 2011 at 06:04, Stefan Sperling <s...@elego.de> wrote: >> > On Sun, Jul 17, 2011 at 05:20:25AM -0400, Greg Stein wrote: >> >> There have been quite a few changes merged into the 1.7.x branch. How >> >> about nuking this tarball, and rolling a new one? We *know* this >> >> tarball isn't what we'd like to deliver to users, so why should we >> >> bother posting it? >> > >> > The point of pre-releases is to find regressions we don't know about. >> > These could lurk in beta1 just as well as current 1.7.x. >> > >> > Stuff we have merged into 1.7.x can be listed as known problems >> > for beta1 which will be fixed in beta2. >> >> Sure, but we haven't even released beta1 yet. I'm saying that we nuke >> it as "already not what we want to deliver". >> >> At the "beta" point, it seems that we'd really like to be much closer >> to reality. Alphas are pretty throw-away, but betas... we want to be >> close. And we already know that this unreleased beta1 doesn't match >> what we want to release.
The "long" delay between rolling the tarballs and releasing is compounded by a couple of factors, the primary of which is waiting for the mirror network to sync the tarballs. For instance, when I woke up last Saturday, I noticed Mike and Philip had +1'd the beta release, so I updated the signatures and pushed the beta to w.a.o/dist/subversion. With tigris, I'd have updated the webpages and sent out the release announcement right then, but using ASF infra to mirror the release, we need to wait an extra day[1], putting the "earliest release moment" at sometime Sunday morning. I don't do Subversion-stuffs on Sundays, which means the release was going to be announced this morning. I've noticed this pattern for the alphas as well. All told, that means a series of delays from patch nomination to asf mirror, means that a fix that goes in on a Tuesday waits until the following Monday morning to be released (and that's *if* we get quick sigs and the tarballs don't have any problems). Putting it in that perspective, I think it's probably suboptimal, particularly if we're interested in a rapid-fire series of releases (like betas or RCs). For patch releases, I'm not so concerned (unless it's a critical fix, in which case the 24-hour mirror window can be shorted[2]). Now, some of the delay may be my own slothfulness, and posting tarballs earlier in the week helps with the weekend-induced delays, but there is some minimal amount of time for release creation. During this time, we will probably find and fix bugs, but I don't think it makes sense to scrap an existing pending release and restart the train unless there is something critically wrong with the former. Anyway, as for 1.7.0-beta1, everything is ready to go, but it feels like the sentiment is toward not releasing it, so I won't unless pressed. [1] Yes, I know that per http://www.apache.org/dev/mirrors.html we can give the mirror script a timestamp to shorten the 24-hour window, but in attempting to be a good citizen, I've not done so. [2] But in the case of a critical bugfix, I feel perfectly comfortable using the above technique. > > +1 > > And while we are at it, maybe we shouldn't use the 24 hour delay merging > things back to 1.7 in this phase. > Merging approved patches back directly improves the test coverage. Even if > it is only because the buildbots will directly start building 1.7.x. > > In that case I would suggest that we DO keep the approved+already merged > patches in STATUS for some time for better reviews. > > We can always roll back vetoed patches before the next tag. If folks what to merge immediately, that's fine. In spite of the "we can always revert it" mentality, I've observed a significant status quo bias when it comes to reverting changes. It's not technically hard, we just don't really do it that often, and when a proposal does get going, we instead end up bikeshedding about whether to fix it or revert it, which turns into a major time sink. The idea behind the 24-hour merge window was to avoid that problem, giving people the chance to register their concerns before we do the merge, rather than after. -Hyrum
