Mailing List Archive: SpamAssassin: devel

Time for 3.3.0 beta?

Index | Next | Previous | View Threaded

wtogami at redhat

Nov 16, 2009, 10:23 PM

Post #1 of 15 (1121 views)
Permalink

Time for 3.3.0 beta?

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6155#c162

I just committed the new scores and several manual score adjustments as
noted here.

Time for 3.3.0 beta? Anything else we should do first?

Is this where Justin cuts a tarball and calls for a vote?

Warren Togami
wtogami [at] redhat

Mark.Martinec+sa at ijs

Nov 17, 2009, 5:36 AM

Post #2 of 15 (1091 views)
Permalink

Re: Time for 3.3.0 beta? [In reply to]

On Tuesday 17 November 2009 07:23:33 Warren Togami wrote:
> Time for 3.3.0 beta? Anything else we should do first?

[Warren, elsewhere]:
> I propose we release 3.3.0 beta ASAP, after the scoring commits I just made
> in Bug #6155.
> Prior to 3.3.0 final release we should attempt to fix this bug properly.
> If we cannot, then we should minimally make Bug #6232 not dangerous.

I have some possible solutions for Bug #6232, just haven't decided yet
which one is closest to the intentions of the Net::DNS writers. The
docs about a supposed internal representation is sketchy, the intention
has to be deduced from source code. Docs on the underlying Net::DNS::RR
is much more explicit.

Before the beta I think the problem reports with implications to
compatibility should be resolved, at least to the point where
no further incompatible changes after a beta will be necessary.
In particular I have Bug 6187 and Bug 6203 in mind.

About the 6203, I have some stats collected. Also the AWL race condition:
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=4642#c1
is worrying me. I'm using a workaround (attempt INSERT first, and
if that fails do the UPDATE), but the change is nontrivial, and depends
on a unique key constraint failing to work properly. If you like,
I can submit it for consideration - can be reverted later if not approved.
An alternative is to use ON DUPLICATE KEY UPDATE, but that seems not
to be liked according to Bug 5998.

The suggestion in Bug 4508 (the patch in Comment 3) seems quite useful
and not too intrusive on the current/default usage. Any thoughts on that?
Do we need a CLA from its author?

Btw, there are like two or three small documentation-change requests
there. If someone has some spare cycles, it would be nice to get rid of
these problem reports.

Mark

jm at jmason

Nov 17, 2009, 7:48 AM

Post #3 of 15 (1080 views)
Permalink

Re: Time for 3.3.0 beta? [In reply to]

On Tue, Nov 17, 2009 at 13:36, Mark Martinec <Mark.Martinec+sa [at] ijs> wrote:
> On Tuesday 17 November 2009 07:23:33 Warren Togami wrote:
>> Time for 3.3.0 beta? Anything else we should do first?
>
> [Warren, elsewhere]:
>> I propose we release 3.3.0 beta ASAP, after the scoring commits I just made
>> in Bug #6155.
>> Prior to 3.3.0 final release we should attempt to fix this bug properly.
>> If we cannot, then we should minimally make Bug #6232 not dangerous.
>
> I have some possible solutions for Bug #6232, just haven't decided yet
> which one is closest to the intentions of the Net::DNS writers. The
> docs about a supposed internal representation is sketchy, the intention
> has to be deduced from source code. Docs on the underlying Net::DNS::RR
> is much more explicit.

IMO we could release a beta with this unfixed, jsut to get rules tested. WDYT?

> Before the beta I think the problem reports with implications to
> compatibility should be resolved, at least to the point where
> no further incompatible changes after a beta will be necessary.
> In particular I have Bug 6187 and Bug 6203 in mind.

6187: ok. let's fix it.

6203: I don't particularly care either way; if someone wishes to fix
it before release, great.

> About the 6203, I have some stats collected. Also the AWL race condition:
> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=4642#c1
> is worrying me. I'm using a workaround (attempt INSERT first, and
> if that fails do the UPDATE), but the change is nontrivial, and depends
> on a unique key constraint failing to work properly. If you like,
> I can submit it for consideration - can be reverted later if not approved.
> An alternative is to use ON DUPLICATE KEY UPDATE, but that seems not
> to be liked according to Bug 5998.

If you can provoke Michael into a response ;) and get agreement, then whatever
you guys decide is good. However I don't think it is safe to delay
beta release
for this, as it's a pretty thorny problem AFAICT.

> The suggestion in Bug 4508 (the patch in Comment 3) seems quite useful
> and not too intrusive on the current/default usage. Any thoughts on that?
> Do we need a CLA from its author?

It does look pretty good, but code-volume-wise I think we would need a CLA.

> Btw, there are like two or three small documentation-change requests
> there. If someone has some spare cycles, it would be nice to get rid of
> these problem reports.

I suggest we ensure that tickets use these priorities:

P1 = must be fixed before 3.3.0 beta release
P2 = must be fixed before 3.3.0 GA release
P3 = nice to fix before GA, but should not impede things
P4, P5 = not really that important

once we get through all the P1s, we're ready to go ;)

--
--j.

parkerm at pobox

Nov 17, 2009, 8:09 AM

Post #4 of 15 (1090 views)
Permalink

Re: Time for 3.3.0 beta? [In reply to]

On Nov 17, 2009, at 9:48 AM, Justin Mason wrote:

> On Tue, Nov 17, 2009 at 13:36, Mark Martinec <Mark.Martinec
> +sa [at] ijs> wrote:
>
>> About the 6203, I have some stats collected. Also the AWL race
>> condition:
>> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=4642#c1
>> is worrying me. I'm using a workaround (attempt INSERT first, and
>> if that fails do the UPDATE), but the change is nontrivial, and
>> depends
>> on a unique key constraint failing to work properly. If you like,
>> I can submit it for consideration - can be reverted later if not
>> approved.
>> An alternative is to use ON DUPLICATE KEY UPDATE, but that seems not
>> to be liked according to Bug 5998.
>
> If you can provoke Michael into a response ;) and get agreement,
> then whatever
> you guys decide is good. However I don't think it is safe to delay
> beta release
> for this, as it's a pretty thorny problem AFAICT.
>

Ok, consider me provoked :)

Commented on bug 5998, my objection wasn't the ON DUPLICATE KEY UPDATE
call, it was on the fact that it would make master-master setups work.

As to the concurrency issues, I learned just enough plpgsql to come up
with those functions and have probably forgotten it, someone with
better PostgreSQL skills needs to pick up the ball and figure things
out.

Michael

kmcgrail at pccc

Nov 17, 2009, 8:35 AM

Post #5 of 15 (1093 views)
Permalink

Re: Time for 3.3.0 beta? [In reply to]

> IMO we could release a beta with this unfixed, jsut to get rules tested.
> WDYT?

+1

>> The suggestion in Bug 4508 (the patch in Comment 3) seems quite useful
>> and not too intrusive on the current/default usage. Any thoughts on that?
>> Do we need a CLA from its author?
>
> It does look pretty good, but code-volume-wise I think we would need a
> CLA.

Definitely.

> I suggest we ensure that tickets use these priorities:
>
> P1 = must be fixed before 3.3.0 beta release
> P2 = must be fixed before 3.3.0 GA release
> P3 = nice to fix before GA, but should not impede things
> P4, P5 = not really that important
>
> once we get through all the P1s, we're ready to go ;)

+1

regards,
KAM

wtogami at redhat

Nov 23, 2009, 9:17 PM

Post #6 of 15 (953 views)
Permalink

Re: Time for 3.3.0 beta? [In reply to]

On 11/17/2009 11:35 AM, Kevin A. McGrail wrote:
>> I suggest we ensure that tickets use these priorities:
>>
>> P1 = must be fixed before 3.3.0 beta release
>> P2 = must be fixed before 3.3.0 GA release
>> P3 = nice to fix before GA, but should not impede things
>> P4, P5 = not really that important
>>
>> once we get through all the P1s, we're ready to go ;)

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6187
This remains the only bug with P1 blocking beta release.

Is this really important enough to block us from moving forward? We
could get some valuable testing by pushing out the beta, the first
release with our new scores.

Warren

wtogami at redhat

Nov 27, 2009, 9:17 AM

Post #7 of 15 (889 views)
Permalink

Re: Time for 3.3.0 beta? [In reply to]

It seems that we are now ready for 3.3.0 beta1.

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6187
This is the last bug, commit needs review.

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6144
Release notes for review

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6155
New scores committed, manual tweaks can still be made

Warren

wtogami at redhat

Nov 30, 2009, 11:21 AM

Post #8 of 15 (836 views)
Permalink

Re: Time for 3.3.0 beta? [In reply to]

Justin is having some difficulties so he suggested that another
committer cut the 3.3.0 beta.

Any objections to doing so today? If no objections I will attempt to do
it myself in a few hours.

Warren Togami
wtogami [at] redhat

wtogami at redhat

Nov 30, 2009, 11:46 AM

Post #9 of 15 (838 views)
Permalink

Re: Time for 3.3.0 beta? [In reply to]

On 11/30/2009 02:21 PM, Warren Togami wrote:
> Justin is having some difficulties so he suggested that another
> committer cut the 3.3.0 beta.
>
> Any objections to doing so today? If no objections I will attempt to do
> it myself in a few hours.
>
> Warren Togami
> wtogami [at] redhat

Hmm, attempting to follow the process in build/README. It seems I don't
have access to people.apache.org. Who do I need to talk to about this?

Warren

Mark.Martinec+sa at ijs

Nov 30, 2009, 12:04 PM

Post #10 of 15 (838 views)
Permalink

Re: Time for 3.3.0 beta? [In reply to]

> Hmm, attempting to follow the process in build/README. It seems I don't
> have access to people.apache.org. Who do I need to talk to about this?

The account on minotaur was supposedly created for you on 2009-10-03.
To reset a password you may need to contact infra:

Date: 3 Oct 2009 03:05:00 -0000
Message-ID: <20091003030500.57386.qmail [at] minotaur>
From: root [at] apache
To: private [at] spamassassin
Subject: [NOTICE] Account created: Warren Togami Jr. (wtogami)

Hi,

The account 'wtogami' was created for Warren Togami Jr. as requested
by this PMC.

Please grant karma to the projects in your domain you wish
the user to have commit to.

The Apache Infrastructure Team

spamassassin at dostech

Nov 30, 2009, 5:44 PM

Post #11 of 15 (833 views)
Permalink

Re: Time for 3.3.0 beta? [In reply to]

On 30/11/2009 2:46 PM, Warren Togami wrote:
> On 11/30/2009 02:21 PM, Warren Togami wrote:
>> Any objections to doing so today? If no objections I will attempt to do
>> it myself in a few hours.
> Hmm, attempting to follow the process in build/README. It seems I don't
> have access to people.apache.org. Who do I need to talk to about this?

I've never been able to build a release myself. I don't have the
release signing key pass-phrase. You'll probably need that too.

Daryl

wtogami at redhat

Nov 30, 2009, 7:46 PM

Post #12 of 15 (831 views)
Permalink

Re: Time for 3.3.0 beta? [In reply to]

On 11/30/2009 08:44 PM, Daryl C. W. O'Shea wrote:
> On 30/11/2009 2:46 PM, Warren Togami wrote:
>> On 11/30/2009 02:21 PM, Warren Togami wrote:
>>> Any objections to doing so today? If no objections I will attempt to do
>>> it myself in a few hours.
>> Hmm, attempting to follow the process in build/README. It seems I don't
>> have access to people.apache.org. Who do I need to talk to about this?
>
> I've never been able to build a release myself. I don't have the
> release signing key pass-phrase. You'll probably need that too.
>
> Daryl
>

Alternatively, might it be acceptable to do the beta release with a
different key?

Warren

spamassassin at dostech

Nov 30, 2009, 8:18 PM

Post #13 of 15 (823 views)
Permalink

Re: Time for 3.3.0 beta? [In reply to]

On 30/11/2009 10:46 PM, Warren Togami wrote:
> On 11/30/2009 08:44 PM, Daryl C. W. O'Shea wrote:
>> I've never been able to build a release myself. I don't have the
>> release signing key pass-phrase. You'll probably need that too.
>
> Alternatively, might it be acceptable to do the beta release with a
> different key?

My preference would be to either obtain the key from (in some secure,
identity confirmed, fashion), or convince one of the following to do the
release (or at least the minimally necessary steps):

- Theo Van Dinter
- Duncan Findlay
- Michael Parker
- Daniel Quinlan

I believe they all know the pass-phrase (in addition to Justin). I
think Malte S. Stretz might know it too.

If after a couple days this route isn't successful we could consider
using a different key.

Going forward, we need to get more of the active people knowledge of the
pass-phrase.

Daryl

Mark.Martinec+sa at ijs

Dec 1, 2009, 3:40 AM

Post #14 of 15 (814 views)
Permalink

Re: Time for 3.3.0 beta? [In reply to]

Daryl wrote:
> - Theo Van Dinter
> - Duncan Findlay
> - Michael Parker
> - Daniel Quinlan
> I believe they all know the pass-phrase (in addition to Justin). I
> think Malte S. Stretz might know it too.

This is a good opportunity for a key transition, as recommended
by ASF. See Bug 6223 and links therein. One of the people
in the know of the current distro-signing key should create a
new one according to recommendations, and sign it with the old one.

Mark

jm at jmason

Dec 1, 2009, 5:58 AM

Post #15 of 15 (808 views)
Permalink

Re: Time for 3.3.0 beta? [In reply to]

On Fri, Nov 27, 2009 at 17:17, Warren Togami <wtogami [at] redhat> wrote:

> It seems that we are now ready for 3.3.0 beta1.
>
>
> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6187
> This is the last bug, commit needs review.
>
> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6144
> Release notes for review
>
> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6155
> New scores committed, manual tweaks can still be made

BTW I think we need to ensure the RescoreMassCheck process has been followed
-- cf bug 6155 -- before a beta is releaseable...

--
--j.

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads