On Mon, Nov 10, 2008 at 1:29 PM, Hyrum K. Wright
<hyrum_wright_at_mail.utexas.edu> wrote:
>>> I propose that the -preN releases don't require the full signature complement,
>>> and that we release them *even with known* issues, while enumerating those
>>> issues as part of the release. I also propose that we use the looser voting
>>> guidelines while still doing -preN releases to aid code mobility into the branch
>>> (while still getting a second set of eyes on it). These changes mirror what we
>>> did early in the 1.5.x release cycle.
>>>
>>> Objections?
>>
>> So you would put out these pre1 etc. releases even when we know the
>> tests are failing? Who would sign them? Also, who do we expect to
>> consume these tarballs?
>
> Yes. Signing of the -pre releases is not a certification that all the tests
> pass, but rather an assurance that the RM hasn't screwed with the tarball. It
> also gives the signers a chance to say "here are the known issues", and for
> testers to tell us any that we missed. I think there is an audience for these
> releases.
Who do you think is the audience? Most of the ones I can think of
would pull from our repos. In terms of the signatures, I understand
what you are saying but what criteria are you expecting people to
apply? Can people still veto? Would the only criteria be that they
feel you messed something up?
It doesn't sound like people need to bother to run the test suite to sign.
Anyway, I do not think producing tarballs immediately and making the
branch this week are directly related so there is probably no need to
continue this discussion. I do not have any objections to making
tarballs, but I know a lot of people are busy stabilizing the release
and I do not think we should ask them to stop and run the normal full
test suite to sign these tarballs. Especially, if we know in advance
that there are a number of failures.
>> I'd like to see out test suite pass, including the bindings before we
>> release anything. I kind of do not think we should branch before then
>> either, but that is more open for debate.
>>
>> I ran all the tests this weekend and the Perl and Ruby bindings are
>> both broken. Other than that, the other test failures are "known" and
>> I've seen discussion about them.
>
> We've got to do *something*, especially if we want to release by the end of the
> year. If folks are willing to let that date slip, just say so, and I'll go back
> in my cave until the appropriate time. Looking back on 1.5, we didn't find a
> number of issues until after we branched. The causation there could be argued,
> but I think it exists, and I think there are other issues we aren't going to
> find until we start pushing code out to the public in the form of prereleases
> (RC or otherwise).
>
> As I asserted elsethread, the way we are developing now, trunk will *always*
> have known issues. If we wait for them to disappear, we'll never branch.
I think you might be exaggerating this a bit. I am not suggesting we
need trunk to be in RC state to make the branch, just that the tests
are passing and the bindings are not broken. I do not recall us
having too much difficulty in the past keeping trunk stable by those
standards. I am pretty certain the tests were passing for 1.5 when we
branched. Perhaps with a number of XFAIL's in place.
I am concerned that the branch will not stabilize if we do not get
trunk a bit more stable before we branch. And there is presumably
nothing preventing us from getting the tests all green by this week
regardless. If we cannot get people interested in getting the tests
working in trunk, what is going to make it happen when we branch?
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-10 19:40:28 CET