[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: 1.5.0-alpha1 tarballs up for testing/signing

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Tue, 26 Feb 2008 10:31:02 -0500

(sorry if this doesn't thread-connect right. I lost context in my mailer.)

Karl Fogel write:
> For alphas, I think Mark's ideas are quite sane.
>
> In fact, the demarcation between "alpha" and "beta" can be that we
> sign the betas (and don't call them official until signed). The RC
> tarballs would follow the same rules as betas, it's just that the
> understanding is it's more serious, because it's going to be the
> actual same bits as the release if it passes muster.

My understanding of the whole point of signatures is that it protects the
community (both the developer community, whose good name is at stake, and
the user community, who places their trust in the developers) from a
misguided RM who has the power to bless Subversion releases. So I don't
like the idea of releasing *anything* without signatures from this community.

> (The above makes me wonder if there's any real need for betas at all,
> but we can cross that bridge when we come to it.)

Yeah, I'm not sure where the breakdown between alpha and beta really is for
us. If anything, I'd claim that we don't have alpha releases (which tend to
be defined as something like mere feature-completeness) at all -- our
pre-RCs are more like betas: "Basically ready to release but with known bugs".

> Anyone object if I adjust
>
> http://subversion.tigris.org/hacking.html#release-stabilization
>
> to reflect this philosophy of getting alphas out for testing more
> easily? (Hyrum should still roll a new one if he can, I think, but
> that doesn't mean testing should stop until then, that's all.)

This is such an objection.

But I want to make something very clear. Nowhere is it implied that our
signatures are a statement of the perfection of a release. I see the
signing process as orthogonal to the perfection of the code. The question
that potential signers should be asking is, "Do I believe this release
represents software that is of the quality that it claims to be, and am I
willing to attach my name to such a declaration?" If we want to release
this alpha1 today with known bugs in the bindings and a failing copy test,
that's *totally fine*. As a potential tester of a release, I'd much rather see:

    This release is signed by the following folks: ... NOTE: We are aware
    of some problems with the Perl and Ruby bindings, so you might not want
    to use this tarball if you need that functionality to work.

than:

    This release has no guarantees, and no testers willing to go on record.
    Best of luck to ya!

In summary:

    * I don't believe this release is of alpha quality; I think it's a beta.
    * I don't care, however, if we call it an alpha.
    * All releases published by this community should be signed.

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on 2008-02-26 16:31:13 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.