[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Savannah-cvs] [579] minor fixes
|
From: |
ineiev |
|
Subject: |
[Savannah-cvs] [579] minor fixes |
|
Date: |
Mon, 13 Feb 2023 05:06:36 -0500 (EST) |
Revision: 579
http://svn.savannah.gnu.org/viewvc/?view=rev&root=administration&revision=579
Author: ineiev
Date: 2023-02-13 05:06:35 -0500 (Mon, 13 Feb 2023)
Log Message:
-----------
minor fixes
Modified Paths:
--------------
trunk/sviki/ImportMailingListArchive.mdwn
trunk/sviki/ListHelperAntiSpam.mdwn
trunk/sviki/MailSystem.mdwn
trunk/sviki/MailingListNotes.mdwn
trunk/sviki/MailingListsInternals.mdwn
trunk/sviki/RecruitingVolunteers.mdwn
trunk/sviki/ResetListPassword.mdwn
trunk/sviki/SavaneTasks.mdwn
trunk/sviki/SavannahAnnounce.mdwn
trunk/sviki/TasksList.mdwn
Modified: trunk/sviki/ImportMailingListArchive.mdwn
===================================================================
--- trunk/sviki/ImportMailingListArchive.mdwn 2023-02-13 10:03:05 UTC (rev
578)
+++ trunk/sviki/ImportMailingListArchive.mdwn 2023-02-13 10:06:35 UTC (rev
579)
@@ -1,9 +1,11 @@
-This page describes the process by which [[SavannahHacker]]s can import
-mailing list archives. If you are a user who would like an archive
-imported, please open a support request at
-<https://savannah.gnu.org/support/?group=administration> with the
-relevant information.
+# Importing mailing list archives
+This page describes the process by which [[Savannah hackers|SavannahHacker]]
+can import mailing list archives. If you are a user who would like an archive
+imported, please open a [support
+request](https://savannah.gnu.org/support/?group=administration)
+with the relevant information.
+
Check [[MailSystem]] for general information on list archives.
The format of the mail archive to import may vary, but we need mbox
@@ -10,13 +12,13 @@
files. Anything else has to be converted. Check for spurious "From "
lines.
-**Public mailing lists**
+## Public mailing lists
-Log in to lists.gnu.org as user list; login as mharc:
+Log in to lists.gnu.org as user list; log in as mharc:
lists:~$ ssh -l mharc lists.gnu.org
-You'll need an archive in one big mailbox. You probably can cat several
+You'll need an archive in one big mailbox. You probably can cat several
mailboxes together if needed (but be sure there is a blank line at the
end of each file first, to avoid running messages together):
@@ -40,16 +42,16 @@
~mharc/bin/web-archive -rebuild $listname >/tmp/mha.out
-If you skip "-rebuild", web-archive will run in incremental mode, i.e.,
-what is used in the cron job. Rebuilding archives can be time-consuming
-and noisy (depending on how many years you have to import). Best to
+If you skip "-rebuild", web-archive will run in incremental mode, i.e.
+what is used in the cron job. Rebuilding archives can be time-consuming
+and noisy (depending on how many years you have to import). Best to
redirect the output as shown above, or whatever.
Then you can check, e.g.,
-<http://lists.nongnu.org/archive/html/$listname>.
+http://lists.nongnu.org/archive/html/$listname.
-**Private mailing lists**
+## Private mailing lists
-Mailman, for archives of private mailing lists, behaves differently. The
+Mailman, for archives of private mailing lists, behaves differently. The
command `~mailman/bin/arch --wipe` will regenerate list archives from a
given mbox file (in the standard mailman location by default).
Modified: trunk/sviki/ListHelperAntiSpam.mdwn
===================================================================
--- trunk/sviki/ListHelperAntiSpam.mdwn 2023-02-13 10:03:05 UTC (rev 578)
+++ trunk/sviki/ListHelperAntiSpam.mdwn 2023-02-13 10:06:35 UTC (rev 579)
@@ -1,9 +1,9 @@
Antispam with listhelper
========================
-If you're using a mailman list on lists.gnu.org for your project(\*),
+If you're using a mailman list on lists.gnu.org for your group,
most incoming spam can be automatically deleted. This is done by
-default for lists created through Savannah. The system is called
+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 (again, this is done by default):
@@ -23,17 +23,17 @@
If you change these settings, we will assume you want to delete all spam
yourself and not use listhelper.
-(\*) Spam removal via listhelper@ is not tied to gnu.org. A few people
-are using it for handling mailman lists outside of Savannahd and GNU as
+- Spam removal via listhelper@ is not tied to gnu.org. A few people
+are using it for handling mailman lists outside of Savannah and GNU 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.
-(\*\*) respond\_to\_post\_requests has nothing to do with the listhelper
+- 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
+- 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
@@ -53,11 +53,10 @@
@nongnu.org for non-GNU lists, but we aren't rigorous about it, and it
makes no practical difference.
-
How it works
------------
-The general idea is that messages that end up in mailman's hold queue
-for the list will be piped through a conservatively-configured
+The general idea is that messages that end up in mailman hold queue
+for the list will be piped through a conservatively configured
spamassassin, bogofilter, and crm114, and 95+% of spam will be
automatically deleted after a short delay (usually measured in minutes,
unless things get backlogged).
@@ -66,7 +65,7 @@
in the hold queue, and need to be approved by a human. (We recommend
adding real addresses to the "accept in the future" list when approving
them.) Thus, you should pay attention to the once-per-day mailman
-notification when there are "pending message(s)", but ignore the
+notification when there are "pending messages", but ignore the
once-per-message mailman notification.
The process does not affect messages from approved members and other
@@ -73,7 +72,7 @@
approved addresses, which continue go through without delay.
Extensive suggestions and comments about many other Mailman
-configuration settings, based on list(helper) experiences over the
+configuration settings, based on listhelper experiences over the
years, are at <http://listhelper.nongnu.org/mailmanconf.html>. Many of
those settings are made by default for Savannah lists.
@@ -85,7 +84,7 @@
-----------------
After some time, we realized that listhelper has problems when most of
the real mail to a list is not in English. This is because the Bayes
-classifier is a large part of the spam/nonspam determination, and it
+classifier is a large part of the spam vs. nonspam determination, and it
doesn't have enough real mail in other languages. Although there's no
way to explicitly determine the language which is mostly used on a given
list, we figured that if the mailman interface language (the
@@ -96,7 +95,7 @@
different interface language, and will continue to do so with new lists
as they arise. We know this makes for extra work for those list
moderators, which we regret, but too much real mail was being deleted.
-We also set max\_days\_to\_hold> to 300 for these lists, since we knew
+We also set max\_days\_to\_hold to 300 for these lists, since we knew
many of them were unattended, and did not want spam to build up
literally forever. 10 months should be enough to handle incoming
messages.
@@ -118,7 +117,7 @@
Nearly every list on lists.gnu.org is checked to some extent. The known
exceptions are those whose administrators explicitly did not want any
-checking, such as FSF member/campaign lists. The exception list is given
+checking, such as FSF member and campaign lists. 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.
@@ -128,9 +127,9 @@
Email-based trackers
--------------------
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
+[[SavaneTasks]] for a bit more) are filtered via the debbugs frontend
Mailman, but still go through listhelper and mailman if it passes that.
-Therefore the message approvals, etc., happen as usual.
+Therefore the message approvals etc. happen as usual.
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
Modified: trunk/sviki/MailSystem.mdwn
===================================================================
--- trunk/sviki/MailSystem.mdwn 2023-02-13 10:03:05 UTC (rev 578)
+++ trunk/sviki/MailSystem.mdwn 2023-02-13 10:06:35 UTC (rev 579)
@@ -1,10 +1,10 @@
-MailSystem
-==========
+Savannah mail system
+====================
See also [[ListServer]] and [[MailingListsInternals]].
The principal GNU (and FSF?) email server is lists.gnu.org, managed by
-FSF sysadmin. Savannah people and programs do not have root access.
+FSF sysadmins. Savannah people and programs do not have root access.
For outgoing mail from Savannah, the `internal` host is used; see below.
@@ -32,28 +32,25 @@
- private archives are managed by Mailman:
`/var/lib/mailman/archives/private/list_name.mbox/list_name.mbox`
- (use mailman's `arch` command to manage them; look at the --wipe command)
+ (use mailman `arch` command to manage them; look at the --wipe command)
- public archives are managed by mharc: `~mharc/mbox` and
`~mharc/html` (check [[ImportMailingListArchive]]).
-
-Mailing-List interface to Savannah's frontend
+Mailing-List interface to Savannah frontend
---------------------------------------------
See [[MailingListsInternals]].
-
-
Valid sender
------------
lists.gnu.org makes (used to make?) a series of checks that will reject
mail from, say, `kickino@savannah.gnu.org` because this is apparently
-not a valid email. Email validation eventually falls-back against
+not a valid email. Email validation eventually falls back against
fencepost (Unix users and the shares `/com/mailer/aliases`).
To bypass those checks, we added aliases at fencepost for Savannah users
-that need to send mail (gatekpr, libcrsync, Savane's INVALID.NOREPLY,
+that need to send mail (gatekpr, libcrsync, Savane INVALID.NOREPLY,
etc.). See also [[ListServer]].
Antispam
@@ -67,9 +64,9 @@
---------------------------------------
A Savane cron job creates alias tables: `/etc/aliases` and
-`/etc/email-addresses`. This is used to map Unix user accounts to an
-outgoing email, based on the `email' field in the user's Savane
-account. Alias tables are only updated on `internal'.
+`/etc/email-addresses`. This is used to map Unix user accounts to
+outgoing email, based on the `email' field in Savannah accounts.
+Alias tables are only updated on `internal'.
- (clearly stale info as we don't own the dom0 any more, but leaving
for what it may be worth) frontend, sftp, vcs-noshell \_and\_ the
@@ -82,18 +79,17 @@
Debugging
---------
-Mail mostly happens from frontend. The PHP there would send the email.
+Mail mostly happens from frontend. PHP there would send email.
If you have a received message in hand, you can see the trail of servers
-in the Received: headers. It starts from PHP. It goes from there to
-/usr/sbin/sendmail (postfix on those systems) and then out to
-eggs.gnu.org, then to lists.gnu.org and out to the mailing list for
-delivery.
+in the Received: headers. It starts from PHP, goes to /usr/sbin/sendmail
+(postfix on those systems) and then out to eggs.gnu.org, then to
+lists.gnu.org and out to the mailing list for delivery.
-If there is an error in sending the PHP and Apache combination should
+If there is an error in sending, PHP and Apache combination should
log an error to the frontend1:/var/log/apache2/error.log file.
All of the mail status should be logged to
-`frontend1:/var/log/mail.*`. When a message is sent you should see
+`frontend1:/var/log/mail.*`. When a message is sent, you should see
the transaction logged there.
Logs are rotated. If you are looking back into the past you will need
Modified: trunk/sviki/MailingListNotes.mdwn
===================================================================
--- trunk/sviki/MailingListNotes.mdwn 2023-02-13 10:03:05 UTC (rev 578)
+++ trunk/sviki/MailingListNotes.mdwn 2023-02-13 10:06:35 UTC (rev 579)
@@ -15,7 +15,7 @@
- ok to approve.
2. If the person has an account on fencepost,
- ok to approve.
-3. If the person is a member of GNU (not nongnu) package(s) on Savannah,
+3. If the person is a member of GNU (not nongnu) package on Savannah,
- ok to approve.
4. When in doubt, ask maintainers@gnu.org before approving.
@@ -30,7 +30,7 @@
------------------------
gnu-prog-discuss is a normal discussion list, with the exception of the
restricted membership. Alternate addresses for members should be
-allowed/approved for posting, etc. Replies are ok.
+approved for posting, etc. Replies are ok.
As described in the maintainers guide, it is best if neither gnu-prog
nor gnu-prog-discuss are ever included in cross-postings including other
Modified: trunk/sviki/MailingListsInternals.mdwn
===================================================================
--- trunk/sviki/MailingListsInternals.mdwn 2023-02-13 10:03:05 UTC (rev
578)
+++ trunk/sviki/MailingListsInternals.mdwn 2023-02-13 10:06:35 UTC (rev
579)
@@ -6,7 +6,7 @@
Savannah admins have only non-root access and are able to perform
limited mailing-list related administration tasks.
-This page describes the interface between savannah's php frontend
+This page describes the interface between Savannah PHP frontend
and the Mailman package running on `lists.gnu.org`. See also:
* [[MailSystem]] - various email and mailing-list related details
@@ -18,24 +18,24 @@
Overview
--------
-Savannah provides mailing lists to hosted projects.
-Project admins can create as many mailing lists as needed through
-the PHP web frontend.
+Savannah provides mailing lists to hosted groups.
+Group admins can create as many mailing lists as needed through
+the web frontend.
The general workflow is as follows:
-1. A project admin on savannah creates a new mailing list on the savannah
+1. A group admin on Savannah creates a new mailing list on Savannah
website.
-2. The PHP frontend code updates the Mailing list information in the
+2. The PHP frontend code updates the mailing list information in the
`mail_group_list` table in the `savane` MySQL database.
3. A cronjob on 'mgt0` reads the `mail_group_list` table and determines
- which operations are needed (e.g. list-creation, password-reset).
+ which operations are needed (e.g. list creation, password reset).
4. The cronjob runs local scripts (on mgt0) for each operation.
5. Each script proxies the commands over SSH to `lists.gnu.org`
-6. On `lists.gnu.org`, The script `scannah_wrapper.pl` processes the commands
+6. On `lists.gnu.org`, the script `scannah_wrapper.pl` processes the commands
and runs the appropriate Mailman scripts locally on `lists.gnu.org`.
7. The cronjob script (back on `mgt0`) sends email notification to the
- project admins (e.g. notification about updated passwords).
+ group admins (e.g. notification about updated passwords).
@@ -55,7 +55,7 @@
status: 5
description: Development discussion for GNU Sed
-To see the mailing-lists for a savannah project:
+To see the mailing lists for a Savannah group:
mysql> select list_name from mail_group_list,groups
where groups.unix_group_name = 'coreutils'
@@ -78,7 +78,7 @@
The `password` field means:
NULL: default value
- '1': A password-reset was requested for this mailing list.
+ '1': A password reset was requested for this mailing list.
The password field should not contain any real passwords,
though the database does contain values besides NULL and '1'
@@ -108,8 +108,8 @@
The PHP code contains these additional comments:
- This frontend php script sets status to:
- 0 if user deletes a list before the backend ever actually created it.
+ This frontend PHP script sets status to:
+ 0 if user deletes a list before the backend ever actually created it
1 if user adds a list
2 if user reconfigures an _existing_ list (ie, status was 5)
@@ -117,13 +117,13 @@
0 when a list is actually deleted
5 when a list is actually created
- - when we create an alias, which mean someone was able, according to
- group type restriction to add to his project a list that was already
- inside the database, we add the list inside the database with a status
- of 5, so sv_mailman does not try to recreate it.
- In the worse case, if two persons creates the same list at the same
+ When we create an alias, which mean someone was able, according to
+ group type restriction, to add to the group a list that was already
+ inside the database, we add the list inside the database with a status
+ of 5, so sv_mailman does not try to recreate it.
- The field password will not contact real password, it will contain
+ In the worst case, if two persons create the same list at the same time,
+ the field password will not contain real password, it will contain
'1' when the backend is supposed to reset it.
@@ -147,11 +147,12 @@
git
<https://git.savannah.gnu.org/cgit/administration/savane.git/tree/backend/mail/sv_mailman.in>).
If you want to modify the script, NEVER update the installed version
-in `/opt/savannah/bin`. ALAWYS update the source version in
-`/opt/savannah/savane/backend/mail/sv_mailman.in` then run `make
-instal` (and of course, check-in the updated version too).
+in `/opt/savannah/bin`. ALAWAYS push the updated version to
+the Savannah repository, update the source version in
+`/opt/savannah/savane/backend/mail/sv_mailman.in`, then run `make
+install`.
-The script reads the `mail_group_list` MySQL table,
+The script reads the `mail_group_list` MySQL table
and performs the required actions based on the `status` and `password`
fields.
@@ -167,7 +168,7 @@
On `mgt0`, symlinks were created to the actual scripts:
- agn@mgt0:~$ ls -lhog /usr/sbin/{newlist,config_list,rmlist}
/usr/lib/mailman/bin/change_pw
+ agn@mgt0:~$ ls -lhog /usr/sbin/{newlist,config_list,rmlist}
/usr/lib/mailman/bin/change_pw
lrwxrwxrwx 1 28 Apr 17 22:44 /usr/lib/mailman/bin/change_pw ->
/opt/savannah/sbin/change_pw
lrwxrwxrwx 1 30 Apr 17 22:43 /usr/sbin/config_list ->
/opt/savannah/sbin/config_list
lrwxrwxrwx 1 26 Apr 17 22:43 /usr/sbin/newlist ->
/opt/savannah/sbin/newlist
@@ -177,11 +178,10 @@
updated version.
NOTE: These scripts are proxies to `lists.gnu.org` - they do not
-perform any local action on `mgt0`. Their names are likely left-over
-from the time the entire savannah system (including Mailman)
+perform any local action on `mgt0`. Their names are likely left over
+from the time the entire Savannah system (including Mailman)
was running on the same local machine.
-
SSH Proxing to lists.gnu.org
----------------------------
@@ -202,7 +202,7 @@
5. When the `newlist` script from `mgt0` connects with SSH to `lists.gnu.org`
instead of getting a shell, the
`lists.gnu.org:/home/list/savannah_wrapper.pl`
script is executed.
-6. This scripts parses limited input from STDIN, and if it contains
+6. This script parses limited input from STDIN, and if it contains
recognized commands and parameters, it runs the corresponding program
locally on `lists.gnu.org`.
7. `sv_mainman` sends email notification to the administrators of the mailing
@@ -219,8 +219,8 @@
PASSWORD=123456
EOF
-The corresponding code in `lists.gnu.org:/home/list/savannah_wrapper.pl` (
-lots of code omitted for brevity):
+The corresponding code in `lists.gnu.org:/home/list/savannah_wrapper.pl`
+(lots of code omitted for brevity):
...
my %vars;
@@ -238,11 +238,8 @@
== 0) or die "change_pw: $!";
}
-
-
TODO: document the "virtual host" hack (e.g. allowing gnu/nongnu mailing
lists).
-
Logs
----
@@ -256,7 +253,7 @@
[sv_mailman] Sun Apr 9 01:50:02 2017 - work finished
On `lists.gnu.org`, the log file is
`lists.gnu.org:/home/list/savannah_wrapper.log`.
-It contains all the passed parameters (and thus passwords in clear-text):
+It contains all the passed parameters (and thus passwords in clear text):
Tue Apr 18 02:52:06 2017
password = 12345
@@ -263,12 +260,11 @@
list_name = pretest-users
command = change_pw
-
Manual walk-through example - changing password
-----------------------------------------------
-When a project-admin on the savannah website requests password-reset
-for their mailing list, the PHP frontend code sets the corresponding
+When group admins request password reset for their mailing list
+on Savannah website, the PHP frontend code sets the corresponding
`password` field in the `mail_group_list` table to `1`.
Equivalent command:
@@ -320,9 +316,6 @@
lists:~$ change_pw -l pretest-users -p 123456 --quiet
New pretest-users password: 123456
-
-
-
Mailing list creation - FOR REFERENCE ONLY
------------------------------------------
@@ -334,7 +327,7 @@
mail instead of username@sv.gnu.org). Then I wrote a fake
`/usr/sbin/newlist` that connects to list@lists.gnu.org via SSH and call
an helper script there (`savannah_wrapper.pl`). This happens via a
-Savannah public key in list@lists.gnu.org's `authorized_keys` with a
+Savannah public key in list@lists.gnu.org `authorized_keys` with a
`command=` restriction.
There is also an empty `/usr/sbin/config_list` on internal that does
Modified: trunk/sviki/RecruitingVolunteers.mdwn
===================================================================
--- trunk/sviki/RecruitingVolunteers.mdwn 2023-02-13 10:03:05 UTC (rev
578)
+++ trunk/sviki/RecruitingVolunteers.mdwn 2023-02-13 10:06:35 UTC (rev
579)
@@ -1,9 +1,10 @@
-Methods
+# Recruiting Savannah volunteers
-- Add a Savannah job for project administration
+## Methods
+
+- Add a Savannah job for the groupc `administration`
(<https://savannah.gnu.org/people/viewjob.php?group_id=5802&job_id=430>)
-- Ask the GNU Volunteer Coordinators
- (<http://www.gnu.org/volunteers/>).
+- Ask the GNU Volunteer Coordinators (<http://www.gnu.org/volunteers/>).
Unfortunately people we got this way have been very disappointing so
far (they almost didn't contribute).
- Another thing we did to recruit people was to put a big "We need
@@ -11,9 +12,10 @@
put a similar notice at www.gnu.org - but that was already an urgent
situation.
-Training - Project approvals
-----------------------------
+## Training
+### Project approvals
+
(IRC transcript):
Beuc: Well, the "training" I've done until then is:
@@ -32,8 +34,7 @@
Beuc: Giving root access depends on the need (eg is the guy doing any
support request at all?)
and the confidence (does the guy/GIRL! have a minimum sysadmining
experience?)
-Training - Support requests
----------------------------
+### Support requests
A similar "training" can be done by asking the volunteer to keep track
of all requests and provide an existing admin as many information as
@@ -43,8 +44,7 @@
investigate the issues. I (Beuc) proceeded that way, without any form of
access, during my first Savannah weeks :)
-Training - improving Savannah
------------------------------
+### Improving Savannah
First, I need to finish this work on having Savannah easily (and
quickly) replicated in a test install. Optionaly have a test install
Modified: trunk/sviki/ResetListPassword.mdwn
===================================================================
--- trunk/sviki/ResetListPassword.mdwn 2023-02-13 10:03:05 UTC (rev 578)
+++ trunk/sviki/ResetListPassword.mdwn 2023-02-13 10:06:35 UTC (rev 579)
@@ -31,3 +31,7 @@
the password of, go the *Passwords* section, type a new password in a
text editor, copy-paste it the password and confirmation field of the
admin password, and send it by mail to the list admin.
+
+## See also
+
+- [[Mailing list management|MailingListsInternals]]
Modified: trunk/sviki/SavaneTasks.mdwn
===================================================================
--- trunk/sviki/SavaneTasks.mdwn 2023-02-13 10:03:05 UTC (rev 578)
+++ trunk/sviki/SavaneTasks.mdwn 2023-02-13 10:06:35 UTC (rev 579)
@@ -1,26 +1,23 @@
-Savannah was based on the Savane software to interface users and system
-administration. Savane manages a list of services for each project, and
-a list of project members who can access them (some being project admins
-who can add or remove members).
+# Savane task list
-Savane also provide a flexible bug/task/support tracker, with mail
-notifications, field transition hooks, fine-grained permissions, query
-forms, squads, and more.
+Savannah runs on the Savane software. Savane manages a list of
+services for each group, and a list of group members who can access
+them (some being group admins who can add and remove members).
-This page is the Savane Tasks List.
+Savane also provides flexible trackers with mail notifications,
+field transition hooks, fine-grained permissions, query forms,
+squads, and more.
-Current "live" version
-----------------------
+## Current "live" version
-Live code is in the administration project.
+Live code is in the administration group.
The live checkout being used by the active Savannah web server is
-/usr/src/savane on the frontend vhost.
+/opt/savannah/savane on the frontend vhost.
-Getting started with the code
------------------------------
+## Getting started with the code
-Here are a few light / quick tasks for a shallow dive into the code :)
+Here are a few quick tasks for a shallow dive into the code :)
> - <https://savannah.gnu.org/support/?group=administration>
> mentions several minor bugs that are mainly due to PHP E\_STRICT
@@ -28,10 +25,9 @@
> code works. Assigned to:
> - RMS also expressed interest in this small-sized improvement:
>
-> > - Provide a description for all repositories of all SCMs in use,
-> > so user can understand which ones are experimental, or mirrors
-> > (such as Emacs' Git mirror), or canonical/reference, etc.
-> > Assigned to:
+> > - Provide a description for all repositories of all VCS in use,
+> > so user can understand which ones are experimental, mirrors
+> > (such as Emacs Git mirror), canonical, etc.
>
> - Savane attempts to reproduce the good i18n practice from desktop
> apps, including setting the date format using browser-settings
@@ -50,8 +46,7 @@
> - Fix email obfuscation in news Atom feeds - you cannot add contact
> info because of this!
-More important wanted changes
------------------------------
+## More important wanted changes
### Spam
@@ -62,14 +57,14 @@
421" captcha-style box for anonymous posters. This seems to work well.
But spammers now tend to create user accounts anyway. After creating an
account there is no longer any automated blocks to posting and this
-includes posting spam. A voting mechanism to remove spam exists. Project
-owners can vote spam out in one vote. Others require multiple votes to
+includes posting spam. A voting mechanism to remove spam exists. Group
+admins can vote spam out in one vote. Others require multiple votes to
hide posted spam.
Other mecanisms are implemented in Savane, and used at gna.org in
particular, but are not used at Savannah. They include so-called "IP
blacklists" (aka DNSBL), but they are blocking legitimate people from
-login in, because black lists tend to be more and more "white lists"
+loging in, because blacklists tend to be more and more "white lists"
(that is, wide IP ranges are blacklisted and people need to do some work
and prove their good will to get unlisted, which is essentially
whitelisting). DNSBL is often used for email spam, and not so many
@@ -88,8 +83,7 @@
To better understand the tables structure, here are a few manually
queries (Note: several actions are already implemented in the site admin
-interface, such as detect suspect users and IP addresses, and ban users
-or unban IP addresses):
+interface, such as detect suspect users, and remove users):
mysql savane # on mgt0 subhost
@@ -139,9 +133,8 @@
DELETE FROM support_cc WHERE email IN (SELECT user_id FROM user WHERE
email="idontexist@nowhere.net");
DELETE FROM task_cc WHERE email IN (SELECT user_id FROM user WHERE
email="idontexist@nowhere.net");
-An improved interface would show an overview all of a user's post
-(bug/task/etc. tracker items, forums/news comments), and offer to treat
-the account as a spammer's, similar to shown above.
+The "Edit user" page in the `siteadmin` area currently lists all
+contributions from the user in trackers.
Starting points from general purposes anti-spam tools:
@@ -213,11 +206,11 @@
> documentation.
> - reduce number of links per posts + surge protection (limit
> msgs/min)
-> - URL block-lists?
+> - URL blocklists?
> - randomized text fields, this prevents reusing the form
>
> > - beware: pre-filling the fields on error
-> > - limit: can't spammers just grab the form and fill-in the fields
+> > - limit: can't spammers just grab the form and fill the fields
> > in order, like humans do, only with garbage? Does this really
> > help? We already have form ids to prevent double-posting forms.
> > Randomizing the form name and URL may be more effective in that
@@ -229,12 +222,12 @@
Ideas (post-moderation):
-> - Currently requires 5 spam points (user=1, tracker admin=2, project
+> - Currently requires 5 spam points (user=1, tracker admin=2, group
> admin=5), but often normal users don't reach 5 points. Implement a
-> moderation form for admins or site-admins, which would be able to
+> moderation form for admins or site admins, which would be able to
> quickly moderate the spam.
>
-> > - Beware: lack of moderation team, lots of dead projects
+> > - Beware: lack of moderation team, lots of dead groups
Other ideas:
@@ -273,17 +266,17 @@
> monthly fee since we're bigger than a classic blog. A free
> software implementation would need a huge traffic too to get
> consistent and reactive detection.
-> - automatically building a list of blocked [[URLs]] from content
-> flagged as spam: spammers may mix some legitimate [[URLs]] in
+> - automatically building a list of blocked URLs from posts
+> flagged as spam: spammers may mix some legitimate URLs in
> their message. When trying this approach, 'bugs.debian.org'
-> appeared in my list of blocked [[URLs]]... This might be used with
+> appeared in my list of blocked URLs... This might be used with
> some moderation, but this means manually checking each and every
> URL.
-### Handle multiple repositories per project
+### Handle multiple repositories per group
Except for CVS and SVN, the VCSes we provide can easily support several
-repositories for a single project. For Arch, there's no server-side and
+repositories for a single group. For Arch, there's no server-side and
it's done directly via SFTP. For Git and Hg, we do it manually on
request. So it would be good to have a web interface to manage those
additional subrepositories, plus a backend script to create them on the
@@ -291,10 +284,10 @@
There are several applications for this:
-- reproduce the CVS/SVN concept of "modules" and split a project in
+- reproduce the CVS concept of "modules" and split a group in
different parts
- manage repository metadata (e.g. gitweb or hgweb "description")
-- add a "fork" feature, where people not part of the project (yet)
+- add a "fork" feature, where people not part of the group (yet)
could start a fork; for clarity, they could be stored in a "forks/"
subdirectory
- support non-centralized development models, where each dev has its
@@ -301,8 +294,8 @@
own subrepository, instead of sharing a main repository
In all cases, the subrepositories need to be clearly parented to the
-Savannah project; it's not a way to create arbitrary repositories for
-project that weren't validated through the Savannah project registration
+Savannah group; it's not a way to create arbitrary repositories for
+a group that weren't validated through the Savannah group registration
procedure.
Discussion (TODO: sum it up in this wiki page):
@@ -311,16 +304,15 @@
Apparently Tuxfamily/VHFFS has support for this:
<http://faq.tuxfamily.org/GIT/En>
-### Import SourceForge trackers data
+### Import SourceForge tracker data
-Initial post with discussions:
-<https://savannah.gnu.org/support/?105668>
+[Discussion in Savannah support tracker](//savannah.gnu.org/support/?105668)
Delicate points:
-- Clean-up the Savane tracker a bit, so that creating imported
- items/comments/attachments can be performed using \_functions\_
- rather than copy/pasting the existing code.
+- Clean up the Savane tracker a bit, so that creating imported
+ items can be performed using \_functions\_ rather than
+ copying the existing code.
- Savannah\<-\>SF users mapping
> - Defined manually: can we trust the user? Maybe check if emails
@@ -341,13 +333,13 @@
<http://project.juiblex.co.uk/hg/sf2bz>
- For Trac:
<https://osi.osuosl.org/wiki/TracImport>
-- Apparently there are 3 different export [[URLs]] (is the XML
+- Apparently there are 3 different export URLs (is the XML
different?):
> - <https://sourceforge.net/export/xml_export.php?group_id=GROUPID>
-> (project admin only)
+> (group admin only)
> - <https://sourceforge.net/export/xml_export2.php?group_id=GROUPID>
-> (requires project only)
+> (requires group only)
> -
> <http://sourceforge.net/export/sf_tracker_export.php?atid=TRACKERID&group_id=GROUPID>
> (public)
@@ -355,9 +347,9 @@
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
+own frontend 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
+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.
@@ -369,7 +361,7 @@
when online.
The main problem I can see is spam. We already get spamdexing on
-trackers, I can only image what we'll get through a mail interface...
+trackers, I can only imagine what we'll get through a mail interface...
Studying the Debian BTS (Bug Tracker System - bugs.debian.org), which is
entirely driven by mail and receives little spam, would probably prove
interesting. This post
@@ -376,29 +368,29 @@
<http://lists.debian.org/debian-devel-announce/2007/10/msg00004.html>
has a couple interesting links, namely to their configuration files.
-A note on permissions: the Savane trackers currently rely on heavy
+A note on permissions: Savane trackers currently rely on heavy
authentication and authorization (you may need to have a Savannah
account, and then you may need to be "technician" or "admin" on the
tracker to perform some actions). I do not see how to implement it for a
mail interface. GPG might be used, but is not really suitable for that
purpose. One suggestion is to simply disable tracker permissions if the
-tracker enables the mail interface for it - and proeminently notify the
+tracker enables the mail interface for it - and prominently notify the
user about that fact. Again, the Debian BTS relies on a similar setup
without apparent troubles, but this may need closer investigation.
### Mailing list subscription
-- auto-invite people to these lists on either account or project
+- auto-invite people to these lists on either account or group
creation
> - look for a way to easily invite people (mailing list command?)
-### SCM hooks interface
+### VCS hooks interface
We need to provide users with a web interface to register on-commit
hooks in their repository. For CVS, we already offer several hooks:
webpages on-commit synchronization (site-wide), commit\_prep+log\_accum
-mail notifications (per project, can be used multiple times), cia.vc
+mail notifications (per group, can be used multiple times), cia.vc
notification via XMLRPC.
There's already some work done:
@@ -409,6 +401,6 @@
The code has some limitations. In particular, when removing all hooks at
once, hooks are still kept installed in the system (the replication
model is flawed). Site-wide hooks are currently hard-coded. Last, the
-cron job does not deal with new projects (because they don't have
+cron job does not deal with new groups (because they don't have
registered hooks yet), while it should add the site-wide hooks
nonetheless.
Modified: trunk/sviki/SavannahAnnounce.mdwn
===================================================================
--- trunk/sviki/SavannahAnnounce.mdwn 2023-02-13 10:03:05 UTC (rev 578)
+++ trunk/sviki/SavannahAnnounce.mdwn 2023-02-13 10:06:35 UTC (rev 579)
@@ -1,4 +1,4 @@
-In Feb 2006 we invited Savannah projects admins to the savannah-announce
+In Feb 2006 we invited Savannah group admins to the savannah-announce
mailing list.
We didn't tried to invite 40,000 users because this is a bit much for
@@ -7,7 +7,7 @@
The preferred way to invite people is to use the web interface - there's
no command-line equivalent, and previous attempt to recreate one ended
up sending invites that did not allow users to actually subscribe. So we
-split the admins list and sent invites using 2x200 batches, and not all
+split the admin list and sent invites using 2x200 batches, and not all
in a row to avoid being marked as spammers (we're, still, mass-mailing
with a non-negligeable percentage of dead ones).
Modified: trunk/sviki/TasksList.mdwn
===================================================================
--- trunk/sviki/TasksList.mdwn 2023-02-13 10:03:05 UTC (rev 578)
+++ trunk/sviki/TasksList.mdwn 2023-02-13 10:06:35 UTC (rev 579)
@@ -3,7 +3,7 @@
## Other pages
* [[CVS]] contains some tasks related to the CVS setup
-* [[Git]] presents the progress with <http://git.or.cz/> support
+* [[Git]] presents the progress with <http://git.or.cz/> support
* [[SvNTasks]] explains what we need to improve SVN
* [[SavaneTasks]] gives various ideas (easy and hard) to improve the
Savane software which runs Savannah
@@ -11,22 +11,21 @@
## Web pages
* Accessibility: this would be a good area for a new contributor to
-start on, since changes are independent and (some are) small.
-Many improvements were proposed: perhaps
-[this
message](http://lists.gnu.org/archive/html/savannah-hackers/2015-07/msg00003.html)
-is the best summary; more in a
-[separate public
thread](http://lists.gnu.org/archive/html/savannah-hackers/2015-06/msg00009.html),
-especially
-[this
message](http://lists.gnu.org/archive/html/savannah-hackers/2015-06/msg00009.html)
-and this [private
message](https://lists.gnu.org/mailman/private/savannah-hackers-private/2015-June/003007.html).
+start on, since changes are independent and (some are) small.
+Many improvements were proposed: [a summary of acessibility
+issues](https://lists.gnu.org/archive/html/savannah-hackers/2015-07/msg00003.html)
+was posted on savannah-hackers in 2015; more in [another
+report](https://lists.gnu.org/archive/html/savannah-hackers/2015-06/msg00009.html)
+and a [private
+message](https://lists.gnu.org/mailman/private/savannah-hackers-private/2015-June/003007.html).
## System
* Read-only bind mounts changed in recent kernel, and this results in
/home being read-only when rebooting a vserver. Upgrade util-vserver or
-work-around.
+work-around.
* user katzchen is continously removed and recreated by
-the sv\_users cron job. Investigate.
+the sv\_users cron job. Investigate.
* The Cacti CPU graph is
apparently graphing "idle" when it's graphing "user". This makes people
believe the CPU is loaded, while it's not (cf. Munin CPU graph and the
@@ -35,36 +34,36 @@
## Documentation
* Make a clear, simple, illustrated explanation of the use of SSH
-public keys. That's not a very simple concept (PKI + keygen + passphrase
-+ ssh-agent + ssh-add + pros over password-authentication)
+public keys. That's not a very simple concept (PKI + keygen +
+passphrase + ssh-agent + ssh-add + pros over password-authentication).
-## [[DownloadArea]]
+## Download area
-* Suggest unifying alpha/ftp/download.sv. This could be easily done by
+* Suggest unifying alpha, ftp, download.sv. This could be easily done by
setting Savannah as the main upload area, and have it replicate signed
files to ftp.gnu.org and alpha.gnu.org (this involves adding a new
-download area for GNU projects).
-* Per-project stats?
+download area for GNU packages).
+* Per-group stats?
## Internal
* document backing-up
-* We need to keep several pieces of information out of Savannah:
-- contacts: get something automated to have your local copy in-sync
-- password (TLS CA + Zope + Mailman - others can be found in savannah or
-mysql config files): make a script to maintain a crypted file that
-contains the passes. Optionaly have the order of the passes scrambled at
-each regeneration (so no assumption can be made on several successive
-versions of the file) and do not rely on temporary files during the
-update. Optionaly do not put the passes in a file, but in each of our
-brains, and scrap this whole idea.
+* We need to keep several pieces of information out of Savannah:
+ - contacts: get something automated to have your local copy in-sync
+ - password (TLS CA + Zope + Mailman - others can be found in Savannah or
+ MySQL config files): make a script to maintain a crypted file that
+ contains the passes. Optionaly have the order of the passes scrambled at
+ each regeneration (so no assumption can be made on several successive
+ versions of the file) and do not rely on temporary files during the
+ update. Optionaly do not put the passes in a file, but in each of our
+ brains, and scrap this whole idea.
## Mailing lists
-* Clean-up mailing lists from old spam
+* Clean up mailing lists from old spam
<http://savannah.gnu.org/support/?103933>
-## Translations
+## Translations
Unlike one of our proprietary competitors, we do not have
a translation web interface. Installing Pootle and integrating
@@ -74,16 +73,15 @@
Note: as of 2019, Pootle out-of-box doesn't comply with GNU philosophy
(e.g. it doesn't provide
-[JavaScript labels](https://www.gnu.org/licenses/javascript-labels.html)),
+[JavaScript labels](//www.gnu.org/licenses/javascript-labels.html)),
so it should be substantially patched before deploying.
The Translation Project
-(<http://www.translationproject.org/>)
+(<https://www.translationproject.org/>)
doesn't have tools to edit the .po and .pot per se, but they have a
publication system to manage them by team. It manages a good part of the
-GNU projects, including coreutils and GCC. The source code can be found
-at:
-<http://svn.vrijschrift.org/tp-repo/TP/>
+GNU packages, including coreutils and GCC. The source code can be found
+at <http://svn.vrijschrift.org/tp-repo/TP/>.
Tools to work with .po:
@@ -100,10 +98,10 @@
* Ikiwiki: <http://ikiwiki.info/> (a native
translation plugin using po4a is under development)
-## Wiki
+## Wiki
-Provide a wiki for projects: problems include spam and replication for
-2500+ projects. Or 1 big wiki for everybody, but we need to have a solid
+Provide a wiki for groups: problems include spam and replication for
+2500+ groups. Or 1 big wiki for everybody, but we need to have a solid
spam protection first. The goal is to avoid setting up a wiki that will
be filled with spam, with not enough visitors to fix it (we're not as
big as Wikipedia just yet ;)). Note that [[WikiSpam]] is usually
@@ -120,21 +118,16 @@
could enable or disable, and then see how effective it was.
Another discussion:
-<http://lists.gnu.org/archive/html/savannah-hackers-public/2009-01/msg00003.html>
+<https://lists.gnu.org/archive/html/savannah-hackers-public/2009-01/msg00003.html>
+* Official .gnu.org web pages need to be validated by maintainers and
+ their team - open wiki can be a problem.
-* Official .gnu.org webpages need to be validated by maintainers and
-their team - open wiki can be a problem
-
-- Work-around: manual sync from temp wiki site to .gnu.org for the
+ - work-around: manual sync from temp wiki site to .gnu.org for the
Hurd Wiki
-- Disallow non-member contribution (not recommended)
+ - disallow non-member contribution (not recommended)
+ - find a nice wiki for that, consuming little resource
+ - or provide a big wiki for everybody
-Find a nice wiki for that, consuming little resource
-
-
-* Or provide a big wiki for everybody
-
-
* Plan something against spam (TextCHA seems to work fine at the
moment)
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Savannah-cvs] [579] minor fixes,
ineiev <=