BTW, I am entirely in favour of changing other people's sandbox rules, if they are making it into production, haven't been touched in several months and are likely unmaintained. (It might be friendly to mail them to notify that you're making the change, however, but that's up to you, ymmv.)
--j. On Mon, Jan 17, 2011 at 09:20, <[email protected]> wrote: > https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6533 > > --- Comment #1 from Warren Togami <[email protected]> 2011-01-17 04:20:01 UTC > --- > This is indeed a serious issue. > > svn commit: r1025769 - > /spamassassin/trunk/rulesrc/sandbox/maddoc/99_fsl_testing.cf > > This was added to trunk in on October 20th, 2010 > > I guess this confirms that we do indeed have auto-promotion of rules from > trunk > to the 3.3.x sa-update channel. It seems this point isn't clear to committers > and thus mistakes are being made. I sincerely hope the PMC can generally > clarify the current processes so easy to understand procedures can be written > down. > > Mistakes > ======== > If I understand this situation correctly, here are a few of the mistakes... > > 1) Lack of clear understanding by committers of how rules are auto-promoted. > > 2) Lack of clear understanding by committers that the scores written in > sandbox > files are IGNORED by the scoring mechanism. This is obviously a "prejudiced" > rule that works great for many users but is wrong for others. Indeed maddoc > knew this, thus he committed a score of 0.01 to the sandbox with the intent of > making it informational only. > > 3) Lack of clear understanding by committers that such "prejudiced" rules > should never be committed to the sandbox without "tflags nopublish". > > 4) Our nightly masscheck corpora is apparently devoid of Russian ham, which > would have caused this rule to fail auto-promotion. > > > Questions for PMC > ================= > 1) I have been asked to not make changes to other people's sandboxes. But > should I avoid doing so if the change is obviously correct like in this > instance? > > 2) Do we have a mechanism to force a sa-update push? Bug #6365 seems to > indicate that we don't yet. > > -- > Configure bugmail: > https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are the assignee for the bug. >
