[Savannah-cvs] [82] stuff about debbugs.gnu.org and listhelper

[karl]

Revision: 82
          http://svn.sv.gnu.org/viewvc/?view=rev&root=administration&revision=82
Author:   karl
Date:     2014-04-01 17:29:05 +0000 (Tue, 01 Apr 2014)
Log Message:
-----------
stuff about debbugs.gnu.org and listhelper

Modified Paths:
--------------
    trunk/sviki/ListHelperAntiSpam.mdwn
    trunk/sviki/MailWhyNoMailFromSavannah.mdwn
    trunk/sviki/SavaneTasks.mdwn

Modified: trunk/sviki/ListHelperAntiSpam.mdwn
===================================================================
--- trunk/sviki/ListHelperAntiSpam.mdwn 2014-03-12 23:33:57 UTC (rev 81)
+++ trunk/sviki/ListHelperAntiSpam.mdwn 2014-04-01 17:29:05 UTC (rev 82)
@@ -1,10 +1,10 @@
 If you're using a mailman list on lists.gnu.org for your project(\*),
 it's possible to configure mailman to automatically delete most spam.
-This is done by default for lists created through savannah. The system
+This is done by default for lists created through Savannah. The system
 is called listhelper, and its home page is
 <http://listhelper.nongnu.org/>.
 
-Here is how to set it up:
+Here is how to set it up (again, this is done by default):
 
 -   On the General Options page:
 
@@ -18,6 +18,29 @@
 > -   ensure generic\_nonmember\_action=hold
 > -   (recommended) ensure default\_member\_moderation=yes ([\*\*])
 
+If you change these settings, we will assume you want to delete all the
+spam yourself and not use listhelper.
+
+(\*) Actually, the spam removal via listhelper@ is not tied to gnu.org
+in any way. A few people are using it for handling non-GNU mailman lists
+as well. If you'd like to do that, email us. On the other hand, the
+shared moderation help via listhelper-moderate requires a script and
+cron job on the target system.
+
+(\*\*) Actually, respond\_to\_post\_requests has nothing to do with the
+listhelper system. But it's important to do, because it reduces
+backscatter from lists.gnu.org, which in turn decreases our chance of
+being blacklisted.
+
+([\*\*]) Setting default\_member\_moderation=yes protects against the spammers
+who know how to subscribe to a list and then send out their spam. We
+have seen these on gnu.org, although thankfully they are not yet
+widespread. The cost is manually approving new members' first message
+(only).
+
+How it works, what list owners have to do
+-----------------------------------------
+
 Without going into every detail, the result is that message that remain
 in the hold queue will be piped through a conservatively-configured
 spamassassin, and 95+% of spam will be automatically deleted after a
@@ -36,61 +59,54 @@
 Extensive suggestions and comments about many other Mailman
 configuration settings, based on experiences using listhelper over the
 years, are at
-<http://listhelper.nongnu.org/mailmanconf.html>.
+<http://listhelper.nongnu.org/mailmanconf.html>.  Many of those settings
+are made by default.
 
-The system was set up by Bob Proulx, with kibitzing from Karl Berry and
-Oleg Katsitadze. We all attempt to review both the spam and nonspam that
-goes through the system, to try to catch misclassified messages. (Very
-few real messages are classified as spam; the other direction is
-naturally somewhat less precise.) Stats at
-<http://www.proulx.com/mlmgr/stats>.
-
 Please feel free to add other GNU lists, we don't need to be explicitly
 informed. And of course we're happy to answer any questions. And if you
 need help moderating the list, likewise let us know.
 
 Shared moderation: lists @(non)gnu.org can use
-<mailto:address@hidden> as an
-administrator or moderator to help spread the moderation load.
+<mailto:address@hidden> as an administrator or moderator to
+help spread the moderation load.  (There is no difference between
+listhelper[-moderate] @gnu.org and @nongnu.org. We tend to use @gnu.org
+for GNU lists and @nongnu.org for non-GNU lists, but we aren't rigorous
+about it, and it makes no practical difference.)
 
+
 On lists.gnu.org, there is a cron entry (for user
 <http://freefriends.org/~listhelper/moderate>,
 which lists the lists with recent pending messages. (There are many
 other cron entries which are a standard part of mailman installation.)
 
-There is no difference between listhelper[-moderate] @gnu.org and
address@hidden We tend to use @gnu.org for GNU lists and @nongnu.org for
-non-GNU lists, but we aren't rigorous about it, and it makes no
-practical difference.
+Inside listhelper
+-----------------
 
+The system was set up by Bob Proulx, with kibitzing from Karl Berry. We
+all attempt to review both the spam and nonspam that goes through the
+system, to try to catch misclassified messages. (Very few real messages
+are classified as spam; the other direction is naturally somewhat less
+precise.) Stats at <http://www.proulx.com/mlmgr/stats>.
+
 We do not claim this is anything like an optimal or efficient system.
 But it is what we could do now, without requiring deep mail system
 infrastructure changes. Maybe someday a better system will be possible.
 
-(\*) Actually, the spam removal via listhelper@ is not tied to gnu.org
-in any way. A few people are using it for handling non-GNU mailman lists
-as well. If you'd like to do that, email us. On the other hand, the
-shared moderation help via listhelper-moderate requires a script and
-cron job on the target system.
+Nearly every list on lists.gnu.org is checked to some extent. The known
+exceptions are those which explicitly did not want any checking, such as
+fsfe-uk, bug-freedink, Aubrey's lists (slib|jacal|scm|wb)-[\*], FSF
+member/campaign lists, etc. The exception list is given in the file
+`~list/etc/ignorelists.egrep` on lists.  We spend about 15 minutes a day
+x 2 volunteers dealing with the normal flow, on average.
 
-(\*\*) Actually, respond\_to\_post\_requests has nothing to do with the
-listhelper system. But it's important to do, because it reduces
-backscatter from lists.gnu.org, which in turn decreases our chance of
-being blacklisted.
+Email-based trackers
+--------------------
 
-([\*\*]) Setting default\_member\_moderation=yes protects against the spammers
-who know how to subscribe to a list and then send out their spam. We
-have seen these on gnu.org, although thankfully they are not yet
-widespread. The cost is manually approving new members' first message
-(only).
+The email-based trackers at <http://debbugs.gnu.org> (see the section in
+[[SavaneTasks]] for a bit more) are filtered via the debbugs front-end
+Mailman, but still go through listhelper and mailman if it passes that.
+Therefore the message approvals, etc., happen as usual.
 
-Admin-side preview
-------------------
-
-Work-load: about 15 minutes a day x 3 volunteers, on average.
-
-Nearly every list on lists.gnu.org is checked to some extent. The known
-exceptions are those which explicitly did not want any checking, such as
-fsfe-uk, bug-freedink, Aubrey's lists (slib|jacal|scm|wb)-[\*], FSF
-member/campaign lists, etc. The exception list is implemented in the
-script \~/bin/oldestheld on lists.
+When trying to re-vivify a message for one of the debbugs lists, look at
+<http://debbugs.gnu.org/cgi-bin/mailman/admindb/debbugs-submit>.  It
+won't show up in the regular queue on lists.gnu.org.

Modified: trunk/sviki/MailWhyNoMailFromSavannah.mdwn
===================================================================
--- trunk/sviki/MailWhyNoMailFromSavannah.mdwn  2014-03-12 23:33:57 UTC (rev 81)
+++ trunk/sviki/MailWhyNoMailFromSavannah.mdwn  2014-04-01 17:29:05 UTC (rev 82)
@@ -1,16 +1,17 @@
 Why do I receive no mail from Savannah?
+---------------------------------------
 
-Well, that depends. It could be that the Savannah system is having
-problems contacting your mail server, or it could be that you (or your
-ISP) deploy a challenge-response-based anti-spam system, where the
-sender must acknowledge (verify) that their email is not spam.
+Almost certainly the mail was filtered as spam on your end.  Check your
+spam filters.
 
-In the latter case, this would mean that when Savannah sends you an
-email (for example, when you register for an account, or when a tracker
-has been altered and you are on it's Cc: list) you will not receive that
-email.
+Less likely, it could be that you (or your ISP) deploy a
+challenge-response-based anti-spam system, where the sender must
+acknowledge (verify) that their email is not spam.  We can't deal with
+such CR-based systems, and, in general, they shouldn't be used.  You
+will need to use an email account that is free of this 'anti-social'
+behavior in order to receive email from Savannah.
 
-Unfortunately, there is nothing we can do about this as we do not have
-the time to act on these verification requests. You will need to use an
-email account that is free of this 'anti-social' behaviour in order to
-receive email from us.
+Less likely yet, it's always possible that the Savannah system is having
+problems contacting your mail server.  If you're not receiving any mail
+at all, try sending a message to yourself from some external place.
+

Modified: trunk/sviki/SavaneTasks.mdwn
===================================================================
--- trunk/sviki/SavaneTasks.mdwn        2014-03-12 23:33:57 UTC (rev 81)
+++ trunk/sviki/SavaneTasks.mdwn        2014-04-01 17:29:05 UTC (rev 82)
@@ -353,9 +353,16 @@
 
 ### Mail interface to the tracker
 
-[Note: the Emacs people are shamelessly setting up a separate debbugs
-instance, so this may not be urgent]
+There is a separate email-based Debian BTS available at
+<http://debbugs.gnu.org> for packages which wish to use it.  It runs its
+own front-end mailman at
+<http://debbugs.gnu.org/cgi-bin/mailman/admindb/debbugs-submit>.  So
+incoming mail to, (say) bug-coreutils goes to that mailman first, then
+into the BTS and then to the normal bug-coreutils as if it had gone
+there in the first place.
 
+Past notes about doing it for the Savannah trackers from Sylvain:
+
 RMS also has interest in this one, because he's often offline. He cannot
 just set down for an hour and browse the Savannah website, but he could
 prepare a batch of trackers mail directives and send them all at once
@@ -379,8 +386,6 @@
 user about that fact. Again, the Debian BTS relies on a similar setup
 without apparent troubles, but this may need closer investigation.
 
-Assigned to:
-
 ### Mailing list subscription
 
 -   auto-invite people to these lists on either account or project