Mailing-List: contact dev-help@spamassassin.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (herse.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
Date: Sat, 3 Mar 2007 16:02:55 -0500
From: Duncan Findlay <duncf@debian.org>
To: Justin Mason <jm@jmason.org>
Cc: dev@spamassassin.apache.org
Subject: Re: VOTE: SpamAssassin 3.2.0 prerelease 2 tarballs
Message-ID: <20070303210255.GB12125@gold>
Mail-Followup-To: Justin Mason <jm@jmason.org>, dev@spamassassin.apache.org
References: <20070228172809.575D132CD9@radish.jmason.org>
 <20070302132212.7FA5032CD9@radish.jmason.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <20070302132212.7FA5032CD9@radish.jmason.org>
User-Agent: mutt-ng/devel-r804 (Debian)

On Fri, Mar 02, 2007 at 01:22:12PM +0000, Justin Mason wrote:

> should we just not bother with votes for prereleases?

> To be honest, I can't see the harm in accidentally pushing a prerelease
> tarball at the wrong time -- and this is the second 3.2.0-preX that isn't
> garnering votes, so clearly the process is getting in the way here. :(

> (Votes for "official" full releases, of course, would still be necessary)

I think by ASF policy, we need a vote. That said, right now a +1 vote means:

 a) I think we should have a pre-release now.
 b) The tarballs presented are well constructed, work well, etc and
I've tested them.

I think if we agree that a +1 vote for pre-release only implies a)
then we won't have the issue of not getting votes. I haven't had time
to test the tarballs, so I haven't voted, but I'm +1 on the idea of a
pre-release. (i.e. +1 to part a) above).

--=20
Duncan Findlay