You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by Jeremy Morton <ad...@game-point.net> on 2013/05/02 20:21:00 UTC

Progress on bug 6890

Hi guys,

Just wondering whether there was any progress on getting bug 6890 into 
the main SpamAssassin codebase:
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6890

I have been using it on my public server for some time now and it's 
working great, no instability or problems.  I have my grey area spam 
coming in, marked as spam, but not totally discarded and it's been 
helpful in a few instances for "grey" e-mail.  And it just requires a 
single bash script on my server because of this threshold commandline 
param.  :-)

-- 
Best regards,
Jeremy Morton (Jez)

Re: Progress on bug 6890

Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Thu, 2013-05-02 at 19:21 +0100, Jeremy Morton wrote:
> Just wondering whether there was any progress on getting bug 6890 into 
> the main SpamAssassin codebase:
> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6890

The quick and upfront answer to the question:  No.

Likely to be perceived as rude, though, and does not explain matters.
So, here goes the verbose reply.


Bugzilla is a tool to file, handle and manage bug reports, as well as
track progress of a report. The term "bug" is a technical one, and valid
reports do include feature requests and tracking their progress, even
though it isn't strictly a "bug".

Synonyms to bug tracker or bug report also commonly used include "issue"
and "problem" as a substitute to "bug". Any difference between these are
not in nature, but exclusively in how the $term tracker is advertised,
used and perceived. The difference also may be none, other than in
terms. For the scope of this essay, I will use the term "bug" to refer
to any flavor or less scary variant.

Any progress, update or status change to a bug will be reflected on the
bug's tracker page. Updates and progress, if any, will also directly and
immediately be notified by email to the folks involved, unless a person
specifically opts-out to certain email. In that case, the bug's page
still reflects the latest status, without sending a notification. People
involved by default include the reporter and the assignee -- for the SA
project the latter is set to default to the dev@ list.

In a nutshell: Any progress will be shown on the bug's page. No change,
no progress, sorry. Any progress and status change will be sent to the
reporter (you) by mail. It will also be sent to the assignee (this very
list) by mail.

Even shorter: Posting an "any updates?" regarding a bug is merely a
ping. The range of possible answers not reflected by the bug tracker
varies between "no" and "no".  ;)


In this case, though, your pinging triggered me to have a look again at
the report. Dammit, this isn't meant to be how it works.

Getting late here, so I'd better get back to the report tomorrow.


> I have been using it on my public server for some time now and it's 
> working great, no instability or problems.  [...]

See, this is something worth noting on the bug report. Not frequently,
of course, but a comment after 3 months, an update of no problems
running in production for that time -- that's worth adding.

It is, after all, a comment state change from "wrote this, works here,
no dead kittens" to "works in production, no single issue in months".


Sincerely,

  /me  -- Someone who likely has spent way too much time with bug
          reports and user support.
          Hopes, he did not just eat all the salt others may apply. ;)

-- 
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}