On Tue, Aug 23, 2011 at 9:10 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> On 08/23/2011 08:17 AM, Bert Huijben wrote:
>>> +1 to release as 1.7.0-RC1 as all tests pass for me. -0 to release as
>>> Subversion 1.7.0
>>
>> Ok, make that a -1 to release as Subversion 1.7.0
>>
>> Subversion working copies that contain 'svn lock'-style locks can't be
>> upgraded by our current upgrade code. (We are mixing two sqlite handles
>> in the upgrade code and the code that inserts a lock checks if a node
>> exists using a db handle that can't look inside the transaction of the
>> other handle)
>>
>> I'm working on a fix and a regression test. (Should be fixed in a few
>> hours)
>
> In IRC, it has been essentially agreed that rc1 is DOA per the bug reported
> (and since fixed) above. The question then becomes, "What do we do with
> RC1?" I've seen these suggestions:
>
> (1) Keep on truckin'. Release it as-is but with a note saying "By the way,
> this won't be the final release candidate.
>
> (2) Re-roll the thing with exactly the same content, and from the same
> magic revision, except with the version tags reading "beta 4" instead of
> "release candidate 1".
>
> (3) Dump the re-release, and focus on a "soon" rc2 instead.
>
> I'd like to register my preference for Option #3
>
> Option #1 -- releasing a release candidate that's not a candidate for
> release -- just doesn't make any sense to me.
>
> Option #2 at least clears up the status of the release to better reflect
> what we know about its lifetime, but I fear we will feel obligated to put
> some "space" between this beta4 and our next real release candidate. This
> "space" would further delay the soak period for the release.
>
> Option #3 doesn't have either of these problems, and -- if we scheduled it
> for this Wednesday or Thursday -- gives us a little more time to address
> Bert's concerns (mentioned elsethread) that we haven't done proper justice
> to the STATUS backport review process. [ I think that's really just secret
> code for "Hey, nobody voted for my stuff!", but ... ;-) ]
I'm fine with #3 happening within the next couple of days.
<aside>
What's interesting here is that this conundrum was effectively caused
by the time between tag-and-release. If we tagged rc1 and tested,
signed, and released it within 24-hours, we wouldn't have known about
the lock problem, and the soak would have started. Whether the lock
problem is enough to warrant a re-soak is debatable, but the general
events may happen again.
In theory, we could end up shooting ourselves and our users in the
feet by scuttling every RC between tag and release as issues become
known. That's obviously a bit absurd, but it's worth asking where we
draw that line?
</aside>
> My goals are simple: I seek to minimize the administrative overhead we
> inflict on ourselves, minimize the number of publicized false starts our
> user base sees, and minimize further unnecessary delay to the release cycle.
> And maximize shareholder value! Oh, and have a pony! And cake ... that I
> get to eat, too!!
Don't forget our synergies!
-Hyrum
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Received on 2011-08-23 19:53:18 CEST