You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by bu...@bugzilla.spamassassin.org on 2011/05/20 07:37:40 UTC

[Bug 6365] need way to cut emergency rule updates with new update-generation system

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

Daryl C. W. O'Shea <sp...@dostech.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |spamassassin@dostech.ca

--- Comment #11 from Daryl C. W. O'Shea <sp...@dostech.ca> 2011-05-20 05:37:40 UTC ---
I've added a script to revert to an existing update version...
build/mkupdates/revert-stable-update

It doesn't solve the problem of making a fast new update, but it does give us
the option of easily rolling back (reverting) to a previous update version.

Reverting to an existing generally known to be good update should be our number
one choice when trying to correct a rule update problem as were not rushing out
a new update that could be broken in its own way.  This works in cases where a
new update introduces a problem, such as a new really bad rule.

It doesn't help us in situation where an old rule turns bad for some reason,
such as our little "Y2K10" rule issue from January 1 last year.  In cases such
as those (which I expect to be much fewer in occurence then the "new bad
update" described above) we'll need to create and release a new update.  I'll
work on this case next.  I think one possible way I may do it is that you
supply a patch to the revert script for it to apply to an existing update (the
script would unpack the existing update, patch it, pack it back up and re-sign
it).

-- 
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.