You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by Michael Parker <pa...@pobox.com> on 2005/04/28 15:45:13 UTC
Moving on to 3.0.4
I'm officially calling 3.0.3 dead and am willing to be the RM for
3.0.4.
It looks like Bug 4287:
http://bugzilla.spamassassin.org/show_bug.cgi?id=4287
has enough votes to be committed, assuming Theo wants to vote for his
own patch.
Once that goes into the 3.0 branch I will be building the 3.0.4
tarballs and putting them up for testing and sending a note to the dev
list, along with the suggested release announcement.
Once I have 3 +1 votes, to the dev mailing list, I will be moving the
files over to /dist/spamassassin so they can begin their journey out
to the Apache mirrors, in addition I'll go ahead and upload to CPAN so
it can make it's way around the CPAN mirrors.
Approximately 12 or so hours after I'll be updating the SA website and
once that rsyncs over I'll make the announcement.
If anyone sees a problem with this schedule, please speak up now.
Thanks,
Michael
Re: Moving on to 3.0.4
Posted by Theo Van Dinter <fe...@kluge.net>.
On Thu, Apr 28, 2005 at 12:58:56PM -0700, Dan Quinlan wrote:
> There is no 24 hour waiting period for release votes. There is no
> vetoing a release in the ASF for EXACTLY this reason.
Our policies aren't specific about release votes vs other votes, and we're not
talking about vetoing.
"Time Delays
Votes should generally be permitted to run for at least 72 hours to provide an
opportunity for all concerned persons to participate regardless of their
geographic locations.
(Since it does say "generally", it seems reasonable exceptions to the 72 hour
rule are allowed if you specify such in your vote, but let's always allow at
least 24 hours or at least 48 hours if the weekend is involved."
In general, having something as important as a release happening before
everyone involved even hears that there's been a vote, again, leads
to disenfranchisement.
--
Randomly Generated Tagline:
"If you build something that any idiot can use, any idiot will."
- Patrick St. Jean
Re: Moving on to 3.0.4
Posted by Daniel Quinlan <qu...@pathname.com>.
Sidney Markowitz <si...@sidney.com> writes:
> in order to accommodate another patch that would have gone into 3.0.3 if
> there had been a 24 hour waiting period for final votes to be collected.
There is no 24 hour waiting period for release votes. There is no
vetoing a release in the ASF for EXACTLY this reason.
Daniel
--
Daniel Quinlan
http://www.pathname.com/~quinlan/
Re: Moving on to 3.0.4
Posted by Sidney Markowitz <si...@sidney.com>.
Warren Togami wrote:
> Why bother pushing another tarball just for a single patch that
> affects only one distribution?
If I understand the preceding discussion correctly this is not a matter of
"release early, release often" carried to an extreme. It is an abort of the
release process for 3.0.3 after the version number has been frozen into a
tarball but before it has been announced. The idea is to abort the release
in order to accommodate another patch that would have gone into 3.0.3 if
there had been a 24 hour waiting period for final votes to be collected.
Michael, is that a correct assessment of the situation?
-- sidney
Re: Moving on to 3.0.4
Posted by Warren Togami <wt...@redhat.com>.
Michael Parker wrote:
> On Thu, Apr 28, 2005 at 05:21:48AM -1000, Warren Togami wrote:
>
>>I do. Why bother pushing another tarball just for a single patch that
>>affects only one distribution? I believe in "release early, release
>>often" for Open Source Software, but is it really a good thing to
>>release for every little change? Even though this one change does
>>benefit me, this is difficult to justify.
>
>
> It also affects anyone who is going to download the tarball and run
> rpmbuild -tb themself. Don't assume that everyone using Fedora or
> RHEL is going to use an "offical" rpm release.
At some point we need to do something about the incompatibility of the
upstream .spec in the tarball and the way RH has shipped spamassassin.
In the past requests to change RH's .spec to become more like the
upstream package split have been vetoed due to upgradability reasons. I
need to revisit this and hopefully move toward convergence in both
upstream and RH's .spec hopefully by for 3.1...
>
>
>>If we do another tarball I would hope for something more meaningful.
>>Outside of bug fixes a recalculation of scores across the board would
>>make 3.0.4 very meaningful, very much like the 2.64 maintenance release.
>
>
> My goal is to make the release stable.
>
Rescoring would make it less stable? (Just curious, you have a lot
more experience in this problemspace than me.)
Otherwise I understand the 3.0.3 abort and agree your plan is good.
Warren Togami
wtogami@redhat.com
Re: Moving on to 3.0.4
Posted by Michael Parker <pa...@pobox.com>.
On Thu, Apr 28, 2005 at 05:21:48AM -1000, Warren Togami wrote:
>
> I do. Why bother pushing another tarball just for a single patch that
> affects only one distribution? I believe in "release early, release
> often" for Open Source Software, but is it really a good thing to
> release for every little change? Even though this one change does
> benefit me, this is difficult to justify.
It also affects anyone who is going to download the tarball and run
rpmbuild -tb themself. Don't assume that everyone using Fedora or
RHEL is going to use an "offical" rpm release.
> If we do another tarball I would hope for something more meaningful.
> Outside of bug fixes a recalculation of scores across the board would
> make 3.0.4 very meaningful, very much like the 2.64 maintenance release.
My goal is to make the release stable.
Michael
Re: Moving on to 3.0.4
Posted by Michael Parker <pa...@pobox.com>.
On Thu, Apr 28, 2005 at 10:17:07AM -0700, Justin Mason wrote:
>
> I'm with Theo on this one -- I by no means consider 4287 a worthwhile
> reason to go to the bother of cutting a 3.0.4. and it *is* a bother!
>
> 4287 can get checked into the 3.0 branch, just in case there's something
> in the future. but it's by no means urgent.
>
Then why the hell was such a big deal made over it yesterday?
Michael
Re: Moving on to 3.0.4
Posted by Michael Parker <pa...@pobox.com>.
On Thu, Apr 28, 2005 at 11:41:16AM -0400, Theo Van Dinter wrote:
>
> But otherwise, I agree with Warren completely. I wanted to get the patch
> in for 3.0.3 because it was trivial and the release wasn't complete at
> that point in time. Now, however, the release has been completed and
> there isn't anything else compelling us to do a 3.0.4 at this point.
>
I had already made the the 3.0.3 tarballs available for testing at
least a half hour before I received the initial mail from Bugzilla for
4287. 40 mins later you expressed a desire to get 4287 into the 3.0
branch, well you said 3.0.3 but that ship had already sailed. So if
it falls to 3.0.4, no big deal, we vote, the patch is committed, and
we do it all over again for 3.0.4.
Consider the 3.0.3 release gone, so the same things that compelled the
3.0.3 release are in place for 3.0.4. Have you changed your mind about
getting 4287 into the 3.0 branch?
Michael
Re: Moving on to 3.0.4
Posted by Theo Van Dinter <fe...@kluge.net>.
On Thu, Apr 28, 2005 at 05:21:48AM -1000, Warren Togami wrote:
> >I'm officially calling 3.0.3 dead and am willing to be the RM for
> >3.0.4.
>
> I do. Why bother pushing another tarball just for a single patch that
> affects only one distribution?
Well, it does affect more than one distribution (for instance, anyone
who makes their own RPMs...)
But otherwise, I agree with Warren completely. I wanted to get the patch
in for 3.0.3 because it was trivial and the release wasn't complete at
that point in time. Now, however, the release has been completed and
there isn't anything else compelling us to do a 3.0.4 at this point.
--
Randomly Generated Tagline:
I loathe people who keep dogs. They are cowards who haven't got the guts
to bite people themselves.
-- August Strindberg
Re: Moving on to 3.0.4
Posted by Warren Togami <wt...@redhat.com>.
Michael Parker wrote:
> I'm officially calling 3.0.3 dead and am willing to be the RM for
> 3.0.4.
>
> It looks like Bug 4287:
> http://bugzilla.spamassassin.org/show_bug.cgi?id=4287
> has enough votes to be committed, assuming Theo wants to vote for his
> own patch.
>
> Once that goes into the 3.0 branch I will be building the 3.0.4
> tarballs and putting them up for testing and sending a note to the dev
> list, along with the suggested release announcement.
>
> Once I have 3 +1 votes, to the dev mailing list, I will be moving the
> files over to /dist/spamassassin so they can begin their journey out
> to the Apache mirrors, in addition I'll go ahead and upload to CPAN so
> it can make it's way around the CPAN mirrors.
>
> Approximately 12 or so hours after I'll be updating the SA website and
> once that rsyncs over I'll make the announcement.
>
> If anyone sees a problem with this schedule, please speak up now.
I do. Why bother pushing another tarball just for a single patch that
affects only one distribution? I believe in "release early, release
often" for Open Source Software, but is it really a good thing to
release for every little change? Even though this one change does
benefit me, this is difficult to justify.
If we do another tarball I would hope for something more meaningful.
Outside of bug fixes a recalculation of scores across the board would
make 3.0.4 very meaningful, very much like the 2.64 maintenance release.
Warren Togami
wtogami@redhat.com
Re: Moving on to 3.0.4
Posted by Duncan Findlay <du...@debian.org>.
On Thu, Apr 28, 2005 at 08:45:13AM -0500, Michael Parker wrote:
> It looks like Bug 4287:
> http://bugzilla.spamassassin.org/show_bug.cgi?id=4287
> has enough votes to be committed, assuming Theo wants to vote for his
> own patch.
>
> Once that goes into the 3.0 branch I will be building the 3.0.4
> tarballs and putting them up for testing and sending a note to the dev
> list, along with the suggested release announcement.
>
> Once I have 3 +1 votes, to the dev mailing list, I will be moving the
> files over to /dist/spamassassin so they can begin their journey out
> to the Apache mirrors, in addition I'll go ahead and upload to CPAN so
> it can make it's way around the CPAN mirrors.
>
> Approximately 12 or so hours after I'll be updating the SA website and
> once that rsyncs over I'll make the announcement.
>
> If anyone sees a problem with this schedule, please speak up now.
I just don't see why we can't change 3.0.3, unless we actually
published it "to the wild". But either way, that's fine.
--
Duncan Findlay