https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5846

           Summary: "Changes" file in distro should include human-readable
                    changes list
           Product: Spamassassin
           Version: unspecified
          Platform: Other
        OS/Version: other
            Status: NEW
          Severity: normal
          Priority: P5
         Component: Building & Packaging
        AssignedTo: [email protected]
        ReportedBy: [EMAIL PROTECTED]


I came across this again:

  http://use.perl.org/~petdance/journal/30809

it's an old moan from Andy Lester about our changes file -- "Here's how to not
do a Changes file: That tells me nothing about whether I want to upgrade my
SpamAssassin install. :-("

it occurred to me that we still substantially have this problem.  I
suggest we fix it by changing our build process so that, instead of
generating "Changes" from svn log, we just cut and paste the history
of build/announcements/*.txt into a single top-level "Changes" file, e.g.


Summary of changes from 3.2.2:
------------------------------

- bug 5548: Certain mail input can take a long time to scan with 100% CPU
  utilisation, due to backtracking in a rule's regexp. fix

[... other changes omitted]

Summary of changes from 3.2.1:
------------------------------

3.2.1 is a major bug-fix release, including a potential local DoS.  The
major highlights are:

- bug 5480: fix for CVE-2007-2873: a local user symlink-attack DoS
  vulnerability. It only affects systems where spamd is run as root, is used
  with vpopmail or virtual users via the "-v"/"--vpopmail" OR
  "--virtual-config-dir" switch, AND with the "-x"/"--no-user-config AND
  WITHOUT the "-u"/"--username" switch AND with the "-l"/"--allow-tell" switch.
  This is not default on any distro package, and is not a common configuration.
  More details of the vulnerability can be read at
  <http://spamassassin.apache.org/advisories/cve-2007-2873.txt>.

[... other changes omitted]

Summary of changes from 3.2.0:
------------------------------

Changes to the core code:

 * new behavior for trusted_networks/internal_networks: the 127.* network is now
always considered trusted and internal, regardless of configuration.

 * bug 3109: short-circuiting of 'definite ham' or 'definite spam' messages
based on individual short-circuit rules using the 'shortcircuit' setting, by
Dallas Engelken <dallase /at/ uribl.com>.

[... 3.2.0 changes omitted]



you get the idea.   As each release goes out, the manual gardening required
is basically just to cut and paste in the *current* release's changes block
into the file.

The svn log is, of course, still available -- in SVN.  so people who
want that can still get it.

sound good?



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

Reply via email to