Bug 5382 - 3.2.0 needs a "summary of major changes" list
Summary: 3.2.0 needs a "summary of major changes" list
Status: RESOLVED FIXED
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Building & Packaging (show other bugs)
Version: SVN Trunk (Latest Devel Version)
Hardware: Other other
: P5 blocker
Target Milestone: 3.2.0
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-03-16 08:53 UTC by Justin Mason
Modified: 2007-05-03 04:48 UTC (History)
0 users



Attachment Type Modified Status Actions Submitter/CLA Status
Edited down Changes file to use as start for making a summary of changes text/plain None Sidney Markowitz [HasCLA]

Note You need to log in before you can comment on or make changes to this bug.
Description Justin Mason 2007-03-16 08:53:10 UTC
this will be required before we can do a full release -- which is
approaching rapidly...

ping, Doc ;)
Comment 1 Doc Schneider 2007-03-16 09:01:59 UTC
I'll try to get this done during the weekend. My $dayjob sure doesn't give me a
lot of free time to sit down to write something which requires me to actually
make sense. HAR!

I'm +1 for kicking Doc in the buttocks to get this done. 
Comment 2 Justin Mason 2007-03-21 11:04:50 UTC
ping ;)
Comment 3 Sidney Markowitz 2007-03-22 00:17:27 UTC
Created attachment 3884 [details]
Edited down Changes file to use as start for making a summary of changes

I edited Changes to delete everything that looked like it doesn't need to go
into a Summary of Changes. I just skimmed over it quickly leaving lots more to
be deleted, but the reduced file has 1414 lines compared to 8269 in the
original. Doc, I hope this helps a bit in your task.
Comment 4 Doc Schneider 2007-03-23 19:16:40 UTC
(In reply to comment #3)
> Created an attachment (id=3884) [edit]
> Edited down Changes file to use as start for making a summary of changes
> 
> I edited Changes to delete everything that looked like it doesn't need to go
> into a Summary of Changes. I just skimmed over it quickly leaving lots more to
> be deleted, but the reduced file has 1414 lines compared to 8269 in the
> original. Doc, I hope this helps a bit in your task.

Where did you save the editted Changes file? The main one is now 8309 lines.

Hopefully you saved it elsewhere. 8*) I am planning on working on this tomorrow
(Saturday) and could really use something now so wieldy. 
Comment 5 Sidney Markowitz 2007-03-23 19:32:59 UTC
> Where did you save the editted Changes file? The main one is now 8309 lines.

Umm, the attachment that I uploaded with comment 3 that you quoted?

(In reply to comment #3)
> Created an attachment (id=3884) [edit] [edit]
> Edited down Changes file to use as start for making a summary of changes

 :-)
Comment 6 Doc Schneider 2007-03-24 07:02:59 UTC
(In reply to comment #5)
> > Where did you save the editted Changes file? The main one is now 8309 lines.
> 
> Umm, the attachment that I uploaded with comment 3 that you quoted?
> 
> (In reply to comment #3)
> > Created an attachment (id=3884) [edit] [edit] [edit]
> > Edited down Changes file to use as start for making a summary of changes
> 
>  :-)
> 


I thought I had looked to see if there was an attachment to that commment, and
now I see there was. Just needed some sleep. 
Thanks Syndey.
Comment 7 Michael Parker 2007-03-28 00:18:49 UTC
Ok, I got a "list" but it still needs some work.  In some cases I just made a
brief comment (ie sa-update stuffs), in other places I just copied an svn
logline.  So things need to be organized a bit more, reworded a bit and probably
need to remove some of these things.

One final note, I'm thinking now, after reading hundreds of Justin's comments
*grin*, that the ruleqa stuff should have been in a separate part of the tree.

Anyway, here is what I came up with, hope it helps.

o IPv6 Support
o spamd: TELL commands disabled by default, use --allow-tell to
  enable.
o bug 4589: allow M::SA::Message to use IO::File objects to read in
  message (same as GLOB).  Also  add in check to ignore unknown
  reference types.
o bug 4517: rule instrumentation plugin hooks, from John Gardiner
  Myers <jgmyers /at/ proofpoint.com>
o The Great Rules Directory reorg
o Rule QA Stuff
o bug 4363: if a message uses CRLF for line endings, we should use it
  as well, otherwise stay with LF as usual
o spamc: Add -K option to ping spamd
o Bug 4515: content preview omits first paragraph when no Subject:
  header
o Received Header parsing updates/fixes/additions
o The tflags multiple thing
o bug 4700: certain privileged configuration settings can inject code,
  due to a bad fix for bug 3846.  Back that out
o add two features to core rule-parsing code; 1. optional behaviour to
  recurse through subdirs looking for .cf/.pre's, to support rules
  compilers working on rulesrc dir.  2. call back into invoking code
  on lint failure, so rule compiler can detect which rules exactly
  fail the lint check
o Bug 3787: Bump HTML::Parser minimum version to prevent mailformed
  UTF-8 errors
o sa-update stuffs
o Bug 4636: Add support for charset normalization
o Bug 4636: Require non-buggy HTML::Parser for charset normalization
o Bugs 4606, 4609: Adjust MIME parsing limits
o trusted_networks/internal_networks fixes/stuffs
o bug 3109: simple short-circuiting of 'definite ham' or 'definite
  spam' messages based on individual short-circuit rules using the
  'shortcircuit' setting, by Dallas Engelken <dallase /at/ nmgi.com>
o bug 4603: Mail::SpamAssassin::Spamd::Apache2 -- mod_perl2 module,
  implementing spamd as a mod_perl module, contributed as a Google
  Summer of Code project by Radoslaw Zielinski
o decided to add a public function to set the rendered information
  instead of expecting plugins to nastily muck with our internal
  data...  bad juju.
o bug 5127: allow mimeheader :raw rules to match newlines and
  folded-header whitespace  in MIME header strings
o Move rule functionality and checking into separate Check plugin.
o bug 3991: spamd can now listen on UNIX domain, TCP, and SSL sockets
  simultaneously.  Command-line semantics extended slightly, although
  fully backwards compatibly; add the --ssl-port switch to allow TCP
  and SSL listening at the same time
o reduce memory footprint by about 750KB by: deleting the source for
  compiled rulesets; deleting stuff used to parse config; compacting
  the descriptions hash into a single string, for more RAM -efficient
  but slower lookups
o DomainKeys/DKIM stuffs
o ArchiveIterator/mass-check cleanups
o sa-compile stuffs
o bug 5206: detect duplicate rules, and silently merge them internally
  for greater efficiency.  This results in about 100-120KB RAM usage
  saving in current svn trunk's ruleset, detecting lots of duplicate
  rules -- so is well worth doing.  also, change t/priorities.t so it
  doesn't accidentally confuse itself with duplicate rules
o Break out of EvalTests into various plugins.
o bug 5236: Support Mail::SPF replacement for Mail::SPF::Query
o bug 5243: add Plugin::register_method_priority() API, allowing
  plugins to control the relative ordering of plugin callbacks
  relative to other plugins' implementations
o bug 3466: do the bayes expiry after results have been passed back to
  the client from spamd, helps avoid client timeouts, etc.
o mass-check client/server mode
o Removed Text::Wrap dependency
o add spamc '-z' switch, which compresses mails to be scanned using
  zlib compression; very useful for long-distance use of spamc over
  the internet.  also add test script, INSTALL doc, and
  documentation.
o bug 4770: add ASN.pm plugin, contributed by Matthias Leisi <matthias
  at leisi.net>
o bug 5296: add spamc --headers switch, which scans messages and
  transmits back just rewritten headers.  This is more
  bandwidth-efficient than the normal mode of scanning, but only works
  for 'report_safe 0'.  Bump spamc/spamd's protocol version to 1.4, to
  reflect new HEADERS verb.   update spamd/PROTOCOL for current
  protocol.  add 'sa-compile' to the SVN ignored-files list.
o bug 5305: implement msa_networks for detecting MSAs and extending
  trust accordingly
o bug 4271: move ImageInfo into 3.2.0 core ruleset
o VBounce Plugin
Comment 8 Justin Mason 2007-03-28 02:37:14 UTC
thanks Michael!

here's a suggestion -- put that up on a page on the wiki ("320ReleaseSummary"
maybe) and make it a collaborative thing.

'One final note, I'm thinking now, after reading hundreds of Justin's comments
*grin*, that the ruleqa stuff should have been in a separate part of the tree.'

bah.  a little scrolling never hurt anyone ;)
Comment 9 Michael Parker 2007-03-28 06:02:05 UTC
http://wiki.apache.org/spamassassin/320ReleaseSummary

Ok, wiki away.
Comment 10 Justin Mason 2007-04-09 04:05:31 UTC
this is mostly done; still need some more info on these items with TODO beside them:

trusted_networks/internal_networks fixes/stuffs [TODO: this needs to mention the
new 127.0.0.1 behaviour!]

sa-update stuffs [TODO: need something more specific here]

DomainKeys/DKIM stuffs [TODO: need something more specific here]



I think the first one is the most important, since it will require config
updates for a lot of users....
Comment 11 Doc Schneider 2007-04-10 15:05:01 UTC
(In reply to comment #10)
> this is mostly done; still need some more info on these items with TODO beside
them:
> 
> trusted_networks/internal_networks fixes/stuffs [TODO: this needs to mention the
> new 127.0.0.1 behaviour!]
> 
> sa-update stuffs [TODO: need something more specific here]
> 
> DomainKeys/DKIM stuffs [TODO: need something more specific here]
> 
> 
> 
> I think the first one is the most important, since it will require config
> updates for a lot of users....


I grabbed what is on the wiki and have started re-writing it to 3.2.0.txt

I know about time. 
Comment 12 Justin Mason 2007-04-12 06:14:13 UTC
thanks -- took that and finished it up, it'll be in rc2.
Comment 13 Justin Mason 2007-05-03 04:48:39 UTC
hey, the changes summary got a good review: http://lwn.net/Articles/232681/

' I agree. I'm a fanatic about changelogs. I review the changelog on every
update to every program on my computer. I found this announcement and changelog
particularly well written, despite knowing little about SA.

Every change was followed by a coherent description long enough so I could get
an idea of the nature of and need for the change, but not so long as to get
bogged down in details I didn't understand. And if I wanted to investigate a
change, adequate information was provided so that I could do some additional
research.

Useful references were provided. Excitement was elicited. Gratuitous hype was
absent.'

;)