[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: Julian Foad <julianfoad_at_btopenworld.com>
Date: Tue, 26 Feb 2008 16:31:20 +0000

+1 to cmpilato's points about signing of releases being important and
orthogonal to perfection.

I would say that if a potential "alpha release" suffers from major problems
that seem to have been recently or accidentally introduced and can be fixed in
a couple of days, then discard that potential release and try again, but if it
suffers from major problems that have been around for a while and are on the
schedule for fixing later, go ahead and sign and release it with these problems
stated plainly.

- Julian

C. Michael Pilato wrote:
> (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.
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-02-26 17:31:39 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.