Proposal: 3.0.3 release schedule

[Warren Togami <wt...@redhat.com>]

Hi folks,

I know everyone here is very busy working on the 3.1.0 release, but I 
work on one of the distributions where major version upgrades are not an 
option.  Duncan similarly is in need of a maintenance release for 
Debian.  So I have been testing the 3.0 branch r122144 for many weeks 
now by pushing it to thousands of our FC4 testers and running it on 
several production servers.  For all intents and purposes the current 
3.0 branch is great, it seems to solve the worst RH Bugzilla reported 
problems from 3.0.1 and 3.0.2 and issues that I personally have observed.

While I believe the current 3.0 branch to be good enough for 3.0.3, for 
thoroughness I spent some time reading through all SA 3.0.x reports and 
3.0.3 milestones.  Below is what I propose for checkin to the 3.0 
branch.  Anything else you would suggest?

======= TRIVIAL STUFF THAT LOOKS SAFE ==========
http://bugzilla.spamassassin.org/show_bug.cgi?id=4191
[review] uri_to_domain() is broken for urls with empty port	

http://bugzilla.spamassassin.org/show_bug.cgi?id=4232
multipart message with 0 parts -> uninitialized in m// (with patch)

http://bugzilla.spamassassin.org/show_bug.cgi?id=4121
[review] Score for user defined rules become ignored

http://bugzilla.spamassassin.org/show_bug.cgi?id=3944
[review] get_envelope_from not handling received header

======== MAYBE ===========
http://bugzilla.spamassassin.org/show_bug.cgi?id=4201
URIBL Tests are looking up email addresses
	No unanimous agreement whether this is the right thing to do.
	SA should decide if they want this behavior in both 3.0.3
	and 3.1.0 (already committed in 3.1.0).

======== DOC CORRECTION ==========
http://bugzilla.spamassassin.org/show_bug.cgi?id=4267
Undocumented obsolete -w switch in spamassassin(1) and usage
	Already fixed in 3.1.0 according to AJ_ZO
	Do doc fixes require R-T-C?


The only uncertainty here is... were there other serious issues fixed in 
trunk but not retargeted for the 3.0.3 milestone?  It would take me far 
longer to dig through all the 3.1.x changes to find the most important 
stuff to backport, so if you happen to think of any very important thing 
fixed that probably affects 3.0.x, please let me know.  I will 
personally do the testing to verify it.

I propose reviewing and committing the above changes, and give it a week 
or two for more testing before release.  I will help in testing by 
pushing this to FC3 and FC4, running it in production on several 
servers, and running any regression tests recommended by the developers.

Thoughts?

Thanks,
Warren Togami
wtogami@redhat.com

Re: Proposal: 3.0.3 release schedule

[Sidney Markowitz <si...@sidney.com>]

Duncan Findlay wrote:
> That's a pretty significant change for a maintenance release.

Yes, and I mention it to bring it to his attention. I guess it's up to him
to decide whether or not to back port the patch, and then it is up to us
whether to accept it in an official 3.0.3 release, just like it is up to us
whether there is any official 3.0.3 release, and it is up to the Fedora crew
what they want to go into their FC4 distro.

I do think that with most of the change being encapsulated in a new object
and with the old code being definitely wrong, they might decide that it is
worth fixing all of those bugs with one change. Personally, I'm the reckless
type who would try to get 3.1 into FC 4. Lucky for them I'm not involved
with that :-)

 -- sidney

Re: Proposal: 3.0.3 release schedule

[Duncan Findlay <du...@debian.org>]

On Thu, Apr 21, 2005 at 09:00:46PM +1200, Sidney Markowitz wrote:
> Warren Togami wrote:
> > The only uncertainty here is... were there other serious issues fixed in
> > trunk but not retargeted for the 3.0.3 milestone?
> 
> What about bug #4260, whose fix also took care of 2352, 3387, 3924, and 3997
> all at the same time?

That's a pretty significant change for a maintenance release.

-- 
Duncan Findlay

Re: Proposal: 3.0.3 release schedule

[Sidney Markowitz <si...@sidney.com>]

Warren Togami wrote:
> The only uncertainty here is... were there other serious issues fixed in
> trunk but not retargeted for the 3.0.3 milestone?

What about bug #4260, whose fix also took care of 2352, 3387, 3924, and 3997
all at the same time?

 -- sidney