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[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
Received on 2011-07-18 19:14:08 CEST