On Mon, Jul 18, 2011 at 4:57 AM, Bert Huijben <bert_at_qqmail.nl> wrote:
>> -----Original Message-----
>> From: Greg Stein [mailto:gstein_at_gmail.com]
>> Sent: zondag 17 juli 2011 12:14
>> To: Hyrum K Wright; dev_at_subversion.apache.org
>> Subject: Re: 1.7.0-beta1 up for testing / signing
>> On Sun, Jul 17, 2011 at 06:04, Stefan Sperling <stsp_at_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, 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).
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
 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.
 But in the case of a critical bugfix, I feel perfectly comfortable
using the above technique.
> 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.
Received on 2011-07-18 19:14:08 CEST