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 2007/07/04 14:58:06 UTC
[Bug 5545] New: switch 3.3.x updates to require "tflags publish"
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5545
Summary: switch 3.3.x updates to require "tflags publish"
Product: Spamassassin
Version: 3.2.1
Platform: Other
OS/Version: other
Status: NEW
Severity: major
Priority: P5
Component: RuleQA
AssignedTo: dev@spamassassin.apache.org
ReportedBy: jm@jmason.org
quoting from a thread from a month ago:
me: 'We currently have this auto-publishing of rules from sandbox to sa-update,
based on how well they do in some automated testing. The thing about
URIBL_RHS_URIBL_BLACK (which is a test rule) made me think, though --
should we modify this to require a more explicit sign-off for the rules
that we want published?
We can already do this (labouriously) by adding "tflags nopublish" to
every rule, or renaming them to have the T_ prefix. What I'm thinking
though, is that rules in sandboxes be implicitly considered "nopublish"
for sa-update use, unless *explicitly* marked "publish".
This would be in addition to the automated testing step, too. In other
words, a rule would have to:
- be in rulesrc/sandbox/whoever/foo.cf
- not named T_SOMETHING
- be listed with "tflags publish"
- pass the QA freqs thresholds
to make it into sa-update.
This was we wouldn't get test rules like URIBL_RHS_URIBL_BLACK (which
seemingly had good enough freqs to be published) getting into updates;
whereas when we write new rules that *are* intended for updates (assuming
they work and catch enough spam), they'll get published easily.
I think that should cut down on the danger of test rules getting
published when we don't want that to happen.'
Kevin A. McGrail: 'As discussed prior, I *thought* the sandbox was a playground
aka wiki sandboxes where it was just lines in the sand washed away by the next
tide. I was very surprised to find out they auto-promoted. I would support the
explicit nature you refer to below.'
Sidney Markowitz: 'I agree. I also assumed that the sandbox was set up like that
until I had occasion to run some test rules. Your proposal makes the whole
process take fewer steps as well as being fail-safe -- There's no need
to remember to use special names or flags when you are first creating a
test rule, and just the step of adding one flag when you are ready to
publish.'
me: 'Yep, that's the idea.
I forgot to mention an additional detail though -- if a publishable meta
rule relies on a testing subrule, it'd have to bring in the subrule
into the publishable set. (That's what the current code does now anyway,
so there isn't much change in that regard)'
Daryl: '+1. I think we actually discussed doing this before, too. At least I
remember sending mail about it.'
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 5545] switch 3.3.x updates to require "tflags publish"
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5545
------- Additional Comments From felicity@apache.org 2007-07-12 09:59 -------
(In reply to comment #16)
> that scales ok when you have a small number of basic rules, but if you then add
> a hundred of those, and start making meta combinations of them, it gets really
> hairy. Imagine fixing the 4000-line (!)
> 'rulesrc/sandbox/emailed/00_FVGT_File001.cf' file to include T_ prefixes on all
> the rules -- then re-fix it each time Fred mails in an updated file. it'd be
> painful.
Well, frankly, I have 2 solutions to that -- perl/another script as you
mentioned, but more realistically: why doesn't Fred just commit his own rules,
then you can let him do that for himself. :)
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 5545] switch 3.3.x updates to require "tflags publish"
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5545
jm@jmason.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status Whiteboard|needs feedback |
------- Additional Comments From jm@jmason.org 2007-07-12 08:27 -------
no comment is good news; I'll go ahead and implement that. (it'll default to
trunk's current behaviour if unspecified.)
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 5545] switch 3.3.x updates to require "tflags publish"
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5545
jm@jmason.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|[review] switch 3.3.x |switch 3.3.x updates to
|updates to require "tflags |require "tflags publish"
|publish" |
------- Additional Comments From jm@jmason.org 2007-07-05 04:11 -------
reverted for now:
: jm 360...; svn commit -m "bug 5545: revert r553198, back to previous 'tflags
publish' behaviour" build/mkupdates/listpromotable
Sending build/mkupdates/listpromotable
Transmitting file data .
Committed revision 553454.
: jm 345...; svn commit -m "bug 5545: revert r553259, r553226, r553206, r553204,
r553200, back to previous 'tflags publish' behaviour in all sandbox rules" rulesrc/
Sending rulesrc/sandbox/emailed/99_alex_dev.cf
Sending rulesrc/sandbox/felicity/70_dnswl.cf
Sending rulesrc/sandbox/felicity/70_iadb.cf
Sending rulesrc/sandbox/jm/20_basic.cf
Sending rulesrc/sandbox/jm/20_dob.cf
Sending rulesrc/sandbox/jm/20_xmailer.cf
Sending rulesrc/sandbox/jm/70_tt_drugs.cf
Transmitting file data .......
Committed revision 553455.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 5545] [review] switch 3.3.x updates to require "tflags publish"
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5545
------- Additional Comments From felicity@apache.org 2007-07-04 20:27 -------
(In reply to comment #7)
> I'm -0.2 on the idea.
>
> I guess I'm at the other end of the spectrum on this one. (All on my own?) If I
> write a rule, I don't want to think about it again. I commit it, and if it's
> good it'll automatically be promoted and I'll never have to think about it
> again. If it's bad, there's no harm in it being left there (and I don't ever
> need to think about it again).
I'm also negative on this idea. If people don't want things published, name the
rule "T_" + something. After development is done, remove the "T_" prefix and
publication happens if it's worthy.
So why do we need to add in a new tflag to give us the same behavior?
On the flip side, I can see the idea of "failing safely" -- ie: assume rules are
in testing, unless someone specifically says no.
IMO, people can just be expected to do the right thing and specify things in
testing versus those which aren't.
As for "If it's bad, there's no harm in it being left there" btw, that's not
necessarily a good way to look at it. As much as "commit a rule and forget it"
makes things easy, there is a cost involved. Specifically, all the
nightly/weekly runs will use all the rules, so having cruft all over the place
is not good.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 5545] [review] switch 3.3.x updates to require "tflags publish"
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5545
spamassassin@dostech.ca changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |
------- Additional Comments From spamassassin@dostech.ca 2007-07-04 14:18 -------
Whoa! Hold on here, there's nothing restricting this to sandbox rules. Rules
that only appear in the legacy rules directory (like all the BAYES_* rules) are
also affected by this.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 5545] switch 3.3.x updates to require "tflags publish"
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5545
------- Additional Comments From jm@jmason.org 2007-07-06 08:32 -------
so, if I put together a patch that implements Daryl's idea -- allow "tflags
publish" to be set to default to yes/no on a file-wide basis -- does that work
for everyone?
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 5545] allow "tflags publish" to be made default/nondefault on a per-file basis
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5545
jm@jmason.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|switch 3.3.x updates to |allow "tflags publish" to be
|require "tflags publish" |made default/nondefault on a
| |per-file basis
------- Additional Comments From jm@jmason.org 2007-07-13 05:05 -------
(In reply to comment #20)
> No, that eliminates one new benefit that I see from this... being able to keep
> the history of a rule, with the same name and in the same file, throughout any
> testing phase the committer may want, all the way through to eventual promotion.
ah, good point Daryl.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 5545] switch 3.3.x updates to require "tflags publish"
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5545
------- Additional Comments From jm@jmason.org 2007-07-12 10:31 -------
(In reply to comment #17)
> Well, frankly, I have 2 solutions to that -- perl/another script as you
> mentioned, but more realistically: why doesn't Fred just commit his own
> rules, then you can let him do that for himself. :)
OK, another example, using rules from a non-committer this time. In fact,
this is the issue that started this whole thing off! Bug 4104.
In that case I took a ruleset attachment from
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4104#c9 and put the
entire thing into svn as rulesrc/sandbox/jm/20_bug4104_uribl.cf . (It was side
effects of that that caused this discussion in the first place! ;)
One purpose of "build/mkrules" is to try to fix the rules code in the sandbox
area, so that it's safe to use with the (more correct, 'safer') distribution
ruleset. For example, it renames rules that duplicate the names of existing
rules, blocks syntax errors from getting into 72_active.cf, and renames rules
marked with "nopublish" to include "T_" as a prefix.
That's what it does. This would be just another case where it's fixing up
possibly-'unsafe' input during "compilation".
Regarding the idea of doing the fix-up with another script prior to checkin,
there's a possible problem with that, which is if there are incremental changes
to the file.
Consider a contributor submits this rule file:
header __BAR Bar =~ /bar/
header BAZ Baz =~ /baz/
header GLOOP Baz =~ /gloop/
header FLOOB Baz =~ /floob/
[... another 50 rules in similar vein]
meta FOO (RCVD_IN_NJABL_SPAM && !__BAR && BAZ && !GLOOP && [...])
(note the reference to 'RCVD_IN_NJABL_SPAM', a distribution rule.)
we run the script and it converts that to:
header __BAR Bar =~ /bar/
header T_BAZ Baz =~ /baz/
header T_GLOOP Baz =~ /gloop/
header T_FLOOB Baz =~ /floob/
[... another 50 rules in similar vein]
meta T_FOO (RCVD_IN_NJABL_SPAM && !__BAR && T_BAZ && !T_GLOOP && [...])
note that 'RCVD_IN_NJABL_SPAM' has not been changed. We check it in. If the
contributor later posts a comment saying "oops! please change these rules: BAZ,
FLOOB, and FOO to read:
header BAZ Baz =~ /baz/
header FLOOB Baz =~ /floob/
meta FOO (RCVD_IN_NJABL_SPAM && !__BAR && !BAZ && !GLOOP && [...])
we no longer have a copy of the original file; we just have the "compiled"
format in SVN. so we now have to hand-convert those new lines to the
"compiled" rule names.
In other words -- it's a bit like checking in compiled output, instead
of the source code, to my mind.
(I guess this kind of incremental updating is annoying and will always require
hand-merging anyway, though, so this isn't a major objection.)
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 5545] [review] switch 3.3.x updates to require "tflags publish"
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5545
------- Additional Comments From spamassassin@dostech.ca 2007-07-04 23:07 -------
I'm a little confused as to why this is needed too. I think I was a little
annoyed by the numerous crap rules that got committed & promoted a month ago
when I agreed with this... I never found the mail I had thought I had sent and
thinking about it more, I think I was going to write a mail opposing the idea.
How many people are committing rules that they don't want published if
appropriate? Is it really more than the number of rules than they do want
published? If there's more than a few rules being committed that aren't
appropriate for publishing, say just to satisfy curiosities, why is this the case?
Rather than have to specify a tflag for every rule, how about (if people don't
want to use T_ rule naming) have something like "testing_rules" that works like
"require_version" where any rules past the marker would be treated as being in
testing. Thus to allow a rule to be published you would just move it above the
marker. This'd also avoid the current issue of needing to add a publish tflag
to every single rule in the base rules directory.
I know that as it is now, any rules I do commit to my sandbox will/would include
the publish tflag... I'm not going to wait for initial results and then go back
and add the tflags... that's what the promotion criteria is for.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 5545] allow "tflags publish" to be made default/nondefault on a per-file basis
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5545
jm@jmason.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|3.2.3 |3.3.0
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 5545] [review] switch 3.3.x updates to require "tflags publish"
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5545
sidney@sidney.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status Whiteboard|needs 1 vote |go
------- Additional Comments From sidney@sidney.com 2007-07-04 13:25 -------
+1
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 5545] [review] switch 3.3.x updates to require "tflags publish"
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5545
maddoc@maddoc.net changed:
What |Removed |Added
----------------------------------------------------------------------------
Status Whiteboard|needs 2 votes |needs 1 vote
------- Additional Comments From maddoc@maddoc.net 2007-07-04 07:01 -------
+1
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 5545] [review] switch 3.3.x updates to require "tflags publish"
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5545
jm@jmason.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|switch 3.3.x updates to |[review] switch 3.3.x
|require "tflags publish" |updates to require "tflags
| |publish"
Status Whiteboard| |needs 2 votes
Target Milestone|Undefined |3.2.2
------- Additional Comments From jm@jmason.org 2007-07-04 06:10 -------
I'm not sure if we've decided how 3.2.x updates are made, but it'd seem
wise to check this into that branch too...
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 5545] switch 3.3.x updates to require "tflags publish"
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5545
------- Additional Comments From jm@jmason.org 2007-07-04 06:09 -------
Created an attachment (id=4029)
--> (http://issues.apache.org/SpamAssassin/attachment.cgi?id=4029&action=view)
patch
here's that implemented. in trunk:
: jm 316...; svn commit -m "bug 5545: 3.3.x updates now require an explicit
'tflags publish' for rules in the rulesrc sandboxes to be published in updates"
build/mkupdates/listpromotable
Sending build/mkupdates/listpromotable
Transmitting file data .
Committed revision 553198.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 5545] allow "tflags publish" to be made default/nondefault on a per-file basis
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5545
jm@jmason.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
------- Additional Comments From jm@jmason.org 2007-07-30 08:36 -------
OK, I've now gone ahead and done this in trunk.
If a sandbox file contains the comment "#testrules", all rules defined beyond
that point will be considered testing rules by the "listpromotable" script, as
if they were named with the "T_" prefix (but without requiring that).
if you want to publish a rule in the "#testrules" scope, add "tflags publish"
and it'll be forced active (as before). in other words, it just affects the
default mode.
since it's a comment, it's fully backwards compatible; SA 2.x, 3.{0,1,2}.x will
all be unaffected if they come across it in a file, and --lint will not notice.
the code is a no-op unless the 'keep_config_parsing_metadata' boolean is on in
the Mail::SA constructor (as it is in the listpromotable script).
: jm 54...; svn commit -m "bug 5545: allow 'tflags publish' to be made
default/non-default on a per-file basis for sandbox rules files, using a
'#testrules' comment"
Sending build/mkupdates/listpromotable
Sending lib/Mail/SpamAssassin/Conf/Parser.pm
Transmitting file data ..
Committed revision 561013.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 5545] switch 3.3.x updates to require "tflags publish"
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5545
------- Additional Comments From jm@jmason.org 2007-07-12 08:53 -------
(In reply to comment #15)
> I still don't see the point. It would let us have "promotion candidate" and
> "testing only" files, but we can already do that with the T_ rule name.
that scales ok when you have a small number of basic rules, but if you then add
a hundred of those, and start making meta combinations of them, it gets really
hairy. Imagine fixing the 4000-line (!)
'rulesrc/sandbox/emailed/00_FVGT_File001.cf' file to include T_ prefixes on all
the rules -- then re-fix it each time Fred mails in an updated file. it'd be
painful.
We could write a script that does this, but why create another script that the
dev has to remember, instead of fixing the update-generation code to do it
automatically...
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 5545] [review] switch 3.3.x updates to require "tflags publish"
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5545
------- Additional Comments From duncf@debian.org 2007-07-04 19:49 -------
I'm -0.2 on the idea.
I guess I'm at the other end of the spectrum on this one. (All on my own?) If I
write a rule, I don't want to think about it again. I commit it, and if it's
good it'll automatically be promoted and I'll never have to think about it
again. If it's bad, there's no harm in it being left there (and I don't ever
need to think about it again). Every once in a while, I should go through my
sandbox and weed out rules that are useless. (Though I'd argue it'd be even
better if something else deleted my crappy rules, but that's a different story
all together...)
I would argue that the vast majority of rules should be automatically
publishable, so requiring tflags publish is a bit laborious. (That said, I don't
regularly look through other peoples' sandboxes, so I could be completely wrong.
Maybe this can be configurable on a per sanbox basis? :-)
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 5545] switch 3.3.x updates to require "tflags publish"
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5545
------- Additional Comments From sidney@sidney.com 2007-07-05 18:48 -------
Reverted my commit to 3.2 branch, with my sincere apologies:
$ svn ci -m "bug 5545: revert r553327 which I never should have committed, back
to previous 'tflags publish' behaviour"
Sending build/mkupdates/listpromotable
Transmitting file data .
Committed revision 553694.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 5545] [review] switch 3.3.x updates to require "tflags publish"
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5545
------- Additional Comments From jm@jmason.org 2007-07-05 03:12 -------
argh. guys, if you oppose the idea, why didn't you all say so when we were
discussing it a month ago? sheesh ;)
The problem is, then, that we have two kinds of rules in sandboxes:
1. rules that should be put in updates, published etc. if they perform well
enough in the nightly mass-checks
2. rules that are just in there for testing in the mass-checks, which we don't
want to see published at all.
What often happens is that we get a ruleset for testing from an external
contributor. this may contain hundreds of rules in class 2. we don't want to
have to laboriously rename them all to use a T_ prefix; that gets hairy very
fast, esp if the contributor does a couple of round trips with changes.
I think I like Daryl's idea best; allow the policy to be set on a file-by-file
basis. it'd be easy to fix build/mkrules to support that. in the meantime I'll
revert the changes I've made to trunk.
btw:
'Whoa! Hold on here, there's nothing restricting this to sandbox rules. Rules
that only appear in the legacy rules directory (like all the BAYES_* rules) are
also affected by this.'
that shouldn't be the case -- they may not wind up listed in the
"rules/active.list" file, but that has no effect, since that file just controls
promotion of rules from the rulesrc sandboxes -- and the legacy rules don't need
to be promoted, they're always in the "rules" dir anyway.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 5545] switch 3.3.x updates to require "tflags publish"
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5545
------- Additional Comments From spamassassin@dostech.ca 2007-07-12 15:38 -------
No, that eliminates one new benefit that I see from this... being able to keep
the history of a rule, with the same name and in the same file, throughout any
testing phase the committer may want, all the way through to eventual promotion.
As far as I can see it really will only affect those who want to use it. Plus,
being able to drop a third-party ruleset in for testing, without having to first
either review all the rules to make sure they are sane, or edit them all so that
they have T_ names would be nice -- basically bug 4104.
One thing to watch out for when implementing it, it really should make the rules
look like test rules to SA -- or at least set (for each rule) tflags to
nopublish and the score to 0.001 so that anyone running trunk with sandbox rules
doesn't end up running with a bunch of test rules with a default score of 1.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 5545] switch 3.3.x updates to require "tflags publish"
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5545
------- Additional Comments From felicity@apache.org 2007-07-12 08:30 -------
(In reply to comment #13)
> so, if I put together a patch that implements Daryl's idea -- allow "tflags
> publish" to be set to default to yes/no on a file-wide basis -- does that work
> for everyone?
I still don't see the point. It would let us have "promotion candidate" and
"testing only" files, but we can already do that with the T_ rule name.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 5545] [review] switch 3.3.x updates to require "tflags publish"
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5545
sidney@sidney.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
Status Whiteboard|go |
------- Additional Comments From sidney@sidney.com 2007-07-04 13:42 -------
Committed to 3.2 branch revision 553327.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 5545] switch 3.3.x updates to require "tflags publish"
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5545
jm@jmason.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |ASSIGNED
Status Whiteboard| |can be deferred to 3.2.3
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 5545] switch 3.3.x updates to require "tflags publish"
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5545
------- Additional Comments From alex.uribl@gmail.com 2007-07-12 15:20 -------
may I suggest two directories per sandbox?
/test
/publish
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 5545] switch 3.3.x updates to require "tflags publish"
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5545
jm@jmason.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status Whiteboard|can be deferred to 3.2.3 |needs feedback
Target Milestone|3.2.2 |3.2.3
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.