[Savannah-cvs] [ListServer] (edit) list import fix; link list renaming page; syntax->rst

[Beuc]

??changed:
-<hr>
-----

??changed:
-
-  Project admins can now create their own mailing lists if they are
-  named PROJECTNAME-*.  This is done through the normal
-  savannah web admin interface, topic Mailing Lists.
-  (What that web interface is ssh to the list server and run newlist;
-  see the MailSystem page.)
-
-  For lists whose names do not follow the PROJECTNAME-* pattern,
-  savannah-hackers must manually run ~/mycreate_list.pl, and then
-  attach the list to the given project using infra/maintenance/ml.pl.
-
-  If the project admin agrees, another option is to have the list
-  use PROJECTNAME-* and thus be created through the web interface,
-  and then create an alias in fencepost:/com/mailer/aliases.  This
-  is recommended for the standard bug-* convention for GNU packages.
-  (Have the project create *-bugs or *-discuss, then make bug-*
-   an alias.)
--------------

Project admins can now create their own mailing lists if they are
named PROJECTNAME-*.  This is done through the normal
savannah web admin interface, topic Mailing Lists.
(What that web interface is ssh to the list server and run newlist;
see the MailSystem page.)

For lists whose names do not follow the PROJECTNAME-* pattern,
savannah-hackers must manually run ~/mycreate_list.pl, and then
attach the list to the given project using infra/maintenance/ml.pl::

 infra/maintenance/ml.pl -a adminsname -g project -l listname
 # check if there's no error
 infra/maintenance/ml.pl -a adminsname -g project -l listname | mysql savane

(someday we'll implement list import in the Savane frontend..)

(that day we'll most probably also allow several mailing lists naming 
conventions for a project group type :))

If the project admin agrees, another option is to have the list
use PROJECTNAME-* and thus be created through the web interface,
and then create an alias in fencepost:/com/mailer/aliases.  This
is recommended for the standard bug-* convention for GNU packages.
(Have the project create *-bugs or *-discuss, then make bug-*
an alias.)

??changed:
-
- You need to edit the list configuration, and the FSF-specific virtual domain 
support (the domains/ subdirectory from the list directory).
-
- Here are the commands::
-------------------------

You need to edit the list configuration, and the FSF-specific virtual domain 
support (the domains/ subdirectory from the list directory).

Here are the commands::

??changed:
-
- We do not remove list archives when it was a public archive. Instead, we 
deactivate a list, while keeping archives and status::
-------------

We do not remove list archives when it was a public archive. Instead, we 
deactivate a list, while keeping archives and status::

??changed:
- Then, in the Privacy form in the mailman interface, set the "advertised" 
variable to "no". TODO: use 'config_list' as with '~/mm-configs/norespond.txt'
Then, in the Privacy form in the mailman interface, set the "advertised" 
variable to "no". TODO: use 'config_list' as with '~/mm-configs/norespond.txt'

??changed:
- If we really want to delete the list, then to tell Mailman to delete a list 
and its settings::
If we really want to delete the list, then to tell Mailman to delete a list and 
its settings::

??changed:
- ... with archives::
... with archives::

++added:
Renaming a mailing list
-----------------------

See RenamingProjectGroup

??changed:
-
- Sometimes people ask to remove a message from the archives,
- because they don't want their address harvested,
- or for some legality, or whatever.
-
- As a policy, we do not have to implement all such requests;
- deletion for spam purposes is typically useless since
- it's already been mirrored in many places.
-
- If you do delete a message, it is usually better to edit it
- to make the body/headers/whatever empty, instead of actually
- deleting it.  Deletion will change all the existing url's.
- Here's the procedure:
------------------------------

Sometimes people ask to remove a message from the archives,
because they don't want their address harvested,
or for some legality, or whatever.

As a policy, we do not have to implement all such requests;
deletion for spam purposes is typically useless since
it's already been mirrored in many places.

If you do delete a message, it is usually better to edit it
to make the body/headers/whatever empty, instead of actually
deleting it.  Deletion will change all the existing url's.
Here's the procedure:

++added:
-----


++added:
---------------------------------------

--
forwarded from 
https://savannah.gnu.org/maintenance/address@hidden://savannah.gnu.org/maintenance