[Savannah-cvs] administration/docs/hacking_savannah hacking_sa...

[Sylvain Beucler]

CVSROOT:        /cvsroot/administration
Module name:    administration
Branch:         
Changes by:     Sylvain Beucler <address@hidden>        04/08/15 17:02:19

Modified files:
        docs/hacking_savannah: hacking_savannah.texi 

Log message:
        Continued work on approval. I consider that chapter OK. It still needs 
work, but it can be truly recommanded to new volunteers.

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/administration/administration/docs/hacking_savannah/hacking_savannah.texi.diff?tr1=1.28&tr2=1.29&r1=text&r2=text

Patches:
Index: administration/docs/hacking_savannah/hacking_savannah.texi
diff -u administration/docs/hacking_savannah/hacking_savannah.texi:1.28 
administration/docs/hacking_savannah/hacking_savannah.texi:1.29
--- administration/docs/hacking_savannah/hacking_savannah.texi:1.28     Sat Aug 
14 17:01:44 2004
+++ administration/docs/hacking_savannah/hacking_savannah.texi  Sun Aug 15 
17:02:19 2004
@@ -1,5 +1,5 @@
 \input texinfo   @c -*-texinfo-*-
address@hidden $Id: hacking_savannah.texi,v 1.28 2004/08/14 17:01:44 Beuc Exp $
address@hidden $Id: hacking_savannah.texi,v 1.29 2004/08/15 17:02:19 Beuc Exp $
 @comment %**start of header
 @setfilename hacking_savannah.info
 @include version.texi
@@ -12,7 +12,6 @@
 
 @indent Copyright @copyright{} 2004 Sylvain address@hidden
 @indent Copyright @copyright{} 2004 Michael address@hidden
address@hidden Copyright @copyright{} 2004 Hugo address@hidden
 @indent Copyright @copyright{} 2004 Rudy address@hidden
 @indent Copyright @copyright{} 2004 Elfyn address@hidden
 @indent Copyright @copyright{} 2004 Mathieu Roy
@@ -44,7 +43,6 @@
 @c by lexical order so as to avoid wars
 @author Sylvain Beucler           (@email{beuc@@gnu.org})
 @author Michael Flickinger (@email{mjflick@@gnu.org})
address@hidden Hugo    Gayosso    (@email{hugo@@gnu.org})
 @author Rudy    Gevaert    (@email{rudy@@gnu.org})
 @author Elfyn   McBratney  (@email{beu@@gnu.org})
 @author Mathieu Roy        (@email{yeupou@@gnu.org})
@@ -1063,6 +1061,17 @@
 @node Projects approval, Terminology, Some quirks, Top
 @chapter Projects approval
 
+When a user wants to host a project at Savannah, he clicks on the
+``Register project'' link in the menu on the left. He is then asked a
+number of questions about his project. This questionnaire is sent to
+the Savannah hackers, who will check if the project complies with the
+Savannah hosting policies. If yes, it is approved. If no, the user
+will be asked to make changes to his project.
+
+This chapter covers everything you need to review project submissions.
+It can be read independly of the rest of this manual, and it primarily
+aimed at new volunteers who may only help with projects reviews.
+
 @menu
 * Prerequisites::               
 * The current situation::       
@@ -1086,73 +1095,49 @@
 its contents. Most often, it is technical or cultural background that
 Savannah hackers need in order to properly do their job.
 
+Specific sections of external resources will be given given
+needed. However, here is a list of more general resources that you
+should now about:
 
address@hidden The current situation, Keeping each other in sync, 
Prerequisites, Projects approval
address@hidden The current situation
-
-Currently, project approvals are underway.
-
-For eight months, projects approvals was not possible for various reasons, 
including, in no particular order:
address@hidden @minus
address@hidden a complete staff change, replaced by people not knowing well of 
Savannah at first
address@hidden internal debates leading to repeated bloated discussions
address@hidden the need to still maintain Savannah and the about 2000 current 
projects
address@hidden the need to reply to user support requests, especially after all 
the post-crack changes
address@hidden the need to audit some parts of Savannah and have them work in 
the new secure infrastructure
address@hidden
address@hidden
+(@pxref{Top,,,maintain, Information For Maintainers of GNU Software}):
+guidelines followed by all GNU maintainers; they are stricter than our
+Savannah policies
address@hidden
+(@pxref{Top,,,standards, The GNU Coding Standards}): are not a
+criteria for Savannah hosting, but sometimes users believe they are
+and will mention this text. It is good to know about it.
address@hidden
address@hidden://www.gnu.org/philosophy/}: the ideas behind the Free
+Software Foundation, that we want to teach our users about. You have
+to know about some of the texts, and agree with them. We have to be
+consistent, and Savannah has to reflect these ideas during user
+communication.
address@hidden
address@hidden://www.gnu.org/licenses/}: licenses links and
+appraisal. Software hosted at Savannah must be GPL-compatible and run
+under a completely free operating system. Deciding whether a software
+complies with this can be tricky, and these web pages will help.
address@hidden
address@hidden (pxref{Approving projects}) is a user-oriented
+compilation of texts to describe most kind of non-compliance with our
+hosting criteria. Be sure to read it entirely by looking at the source
+code; it is very basic E-Lisp code, so you will be able to concentrate
+on the textual contents.
 @end itemize
 
-Several of the issues were solved, allowing the Savannah Hackers to
-start reviewing projects again.
-
-However, there is now a backlog of more than 500 projects to review,
-which is a very long process. Usually one Savannah hacker writes an average of
-4 e-mails related to project approvals per day, and a project usually
-requires several mail exchanges to be completely processed. And of
-course, several new submissions are sent each day.
-
-Most of the old project registrations are irrelevant now. However,
-some people waited for all that time, or wish to move their project
-from another location back to Savannah.
 
-We first sent an announcement to all users who registered a project
-not yet reviewed, asking for people not interested anymore to warn
-us. We also planned to remove old unconfirmed project registrations
-after one month. This was a small mistake, because after one month, we
-would not be able to differentiate between a project still
-interested in being hosted, and an unconfirmed project probably hosted
-somewhere else or dead.
 
-We got confirmations to approve projects, though, so we could start
-working. We also started processing the recent requests, that need not
-confirmation.
-
-As soon as we finish processing this two categories of registrations,
-we plan to send another e-mail soon asking for everyone to confirm the
-status of their hosting request. The one-month limit also proved too
-optimistic, and will be delayed.
-
-
address@hidden Keeping each other in sync, Overview of the approval process, 
The current situation, Projects approval
address@hidden Keeping each other in sync
address@hidden Approving projects
address@hidden Approving projects
 
 We are using the channel #savannah on @uref{irc.freenode.net} to
 coordinate this effort.
 
-Aside from IRC, we are also using a list to keep track of projects,
-that can be checked out using:
address@hidden -d:ext:@var{yourlogin}@@savannah.gnu.org:/cvsroot/administration 
co administration/lists/pending_projects_to_keep.txt}.
 
-You can also see it online at
address@hidden://savannah.gnu.org/@/cgi-bin/@/viewcvs/@/administration/@/administration/@/lists/@/pending_projects_to_keep.txt@/?rev=HEAD&content-type=text/vnd.viewcvs-markup}.
-
-The file is auto-documented. Submissions labelled ``Confirmed and
-Pending'' should be reviewed in priority.
-
-
address@hidden Overview of the approval process, Approval Policies, Keeping 
each other in sync, Projects approval
address@hidden Overview of the approval process
-
-When a user wants to host a project at Savannah, he clicks on the ``Register 
project'' link in the menu on the left. He is then ask a number of questions, 
including:
+Whenever a user submitsa project at Savannah,
+savannah-hackers@@gnu.org receives a notification, including:
 
 @itemize
 @item Name of the project (real name and system name)
@@ -1166,11 +1151,11 @@
 A project is created in the Savannah database, and marked as
 'Pending'. It is not created for real on the system yet.
 
-An e-mail is sent to savannah-hackers@@gnu.org to notify the staff.
-
 Note: at the moment, we maintain a list of submitted project using
-these notifications. We may move the notifications to a separate list
-for ease of use and tasks separation in the near future.
+these notifications. We might also move the notifications to a
+separate list for ease of use and tasks separation in the near
+future. The drawback is that people only subscribed to this list will
+be isolated from the other Savannah events.
 
 Another way to see the pending requests require Savannah administrator
 privileges, accessible in the main menu under 'Pending projects'. One
@@ -1179,10 +1164,10 @@
 page takes a long while to load (it you are willing to fix this, go
 ahead!).
 
-That page also displays the projects descriptions. It doesn't wrap
+That page also displays the projects descriptions. It does not wrap
 lines, though, so it may be better to ask one of the Savannah hackers
 a mailbox with all the projects registrations notifications
-(especially if you did not receive them yourself).
+(especially if you had not received them yourself).
 
 Another lighter but less complete way to list pending projects is to use
 @uref{https://savannah.gnu.org/@/admin/@/grouplist.php?status=P}
@@ -1192,49 +1177,179 @@
 the approval process is done manually using e-mail and mailing lists,
 and you do not need any privilege to use those :)
 
-Then at a point the project is reviewed by a Savannah hacker. If the
-project meats our approval criteria, the project is accepted. Else,
-depending on the closeness to these criteria and the expected delay to
-fix the project, either a mail conversation ensues, either the project
+Then at a point the project is reviewed by a Savannah hacker, who will
+check for compliance with our approval criteria; @xref{Approval
+Criteria}.
+
+Project should be processed chronologically, and you must notify the
+other Savannah hackers that you are working on the submission request
+(usually, by asking on IRC whether anyone is already working on it).
+
+We have an E-Lisp script, savannah.el. It can be used to provide bits
+of canned text that can be pasted in your e-mail reply so as to
+describe each kind of problem precisely, allowing you to gain time.
+
+You can currently download it from
address@hidden/infra/savannah.el} in project administration's
+CVS repository.
+
+To use it, the simplest is to add something like:
address@hidden
+(require 'savannah "~/savannah.el")}
address@hidden lisp
+in your @file{.emacs} configuration file.
+
+Then, a series of commands, prefixed with @code{sv-}, will be
+available through @kbd{M-x}. For example, to begin your answer, type
address@hidden sv-opening}, and this will insert a standard greeting text
+where you cursor is.
+
+If the project meats our approval criteria, the project is
+accepted. Else, either a mail conversation ensues, either the project
 is deleted and people are asked to submit it again.
 
 We feel that it is not very nice for the user to resubmit the project
 each time there is something wrong. It can be a bit more difficult to
 track, though. It is up to you to decide how to handle that part.
 
+It should depend on the closeness to our criteria and the expected
+delay to fix the project: if the project maintainer can provide an
+updated tarball within a few days, it is probably good to handle this
+by mail. If it takes more than one week, it is probably good to delete
+the project and ask the user to register again once it is done.
+
 The main issues is that people cannot modify or add comments to their
 project registrations. Enhencing this feature could be a good thing in
 Savane, feel free to do so ;)
 
-If the project is refused, we mark it as 'Deleted' using the
-administrator web interface, and the system will removed it via a
-cron_job.
-
-(Note: this is not enabled at the moment, deletion has to be done
-manually if necessary).
-
address@hidden project_name --user="rudy@@fencepost"
---comment="reason"} should do the Right Thing, but needs to be checked
-for compliance with the chroot'd repositories.
-
-(Note: the ``Delete project'' button in the ``Pending projects'' page
-is deleting the project from te pending list, but not from the system,
-so you had better not use it at the moment).
-
 If the project is accepted, we mark it as 'Active', still using the
 administrator web interface, and the system will create it within 30
 minutes. We also click on a link that sends the user instructions on
 how to use his Savannah project account.
 
-Note: we currently maintain a list of pending, currently reviewed, and
-approved project. This is necessary because we recently started
-approving new projects, and would like to keep track of which projects
-were accepted in the post-crack slightly different Savannah
-architecture.
+If the project is refused, we mark it as 'Deleted' using the
+administrator web interface, and the system will remove it via a cron
+job @footnote{This is not enabled at the moment, deletion has to be
+done manually if necessary @samp{sv_register_discard project_name
+--user="rudy@@fencepost" --comment="reason"} should do the Right
+Thing, but needs to be checked for compliance with the chroot'd
+repositories.}
address@hidden ``Delete project'' button in the ``Pending projects'' page
+is deleting the project from the pending list, but not from the
+system, so you had better not use it at the moment.}.
+
+All mail exchanges must be sent to @email{savannah-hackers@@gnu.org}
+in carbon copy (Cc). This allows the rest of the team to know the
+status of the project, and possibly find errors in each other's work.
+
+If you are new with project approval, and since it is a delicate task,
+we ask that you send your e-mail reply to one of the 'veteran'
+Savannah hackers (via e-mail or IRC), so he can review your review.
+
+
address@hidden The current situation, Keeping each other in sync, 
Prerequisites, Projects approval
address@hidden The current situation
+
+Currently, project approvals just started again. We are not totally in
+a ``normal'' situation. We will first present the general context of
+Savannah regarding project approvals, and then point to some
+exceptions to take into account
+
+In December 2003, the Savannah machine was compromised. That lead to a
+violent reaction from the FSF: Savannah was closed during one month,
+and the Savannah hackers priviledges were first canceled, then
+partially granted again. Then Savannah was back online, with a
+slightly different architecture (with heavy use of chroot'd
+environment), several features missing until audit or rewrite, some
+other changed. And of course, no projects approval.
+
address@hidden://savannah.gnu.org/forum/forum.php?forum_id=2752}
+that lists changes following the december 2003 Savannah crack.
+
+For eight months, projects approvals was not possible for various
+reasons, including, in no particular order:
address@hidden @minus
address@hidden
+a complete staff change, replaced by people not knowing well of
+Savannah at first
address@hidden
+internal debates leading to repeated bloated discussions
address@hidden
+the need to still maintain Savannah and the about 2000 current
+projects
address@hidden
+the need to reply to user support requests, especially after all the
+post-crack changes
address@hidden
+the need to audit some parts of Savannah and have them work in the new
+secure infrastructure
address@hidden itemize
+
+Several of the issues were solved, allowing the Savannah hackers to
+start reviewing projects again.
+
+However, there is now a backlog of more than 500 projects to review,
+which is a very long process. Usually one Savannah hacker writes an
+average of 3 e-mails related to project approvals per day, and a
+project usually requires several mail exchanges to be completely
+processed. And of course, several new submissions are sent each day.
+
+Most of the old project registrations are irrelevant now. However,
+some people waited for all that time, or wish to move their project
+from another location back to Savannah.
+
+We first sent an announcement to all users who registered a project
+not yet reviewed, asking for people not interested anymore to warn
+us. We also planned to remove old unconfirmed project registrations
+after one month. This was a small mistake, because after one month, we
+would not be able to differentiate between a project still
+interested in being hosted, and an unconfirmed project probably hosted
+somewhere else or dead.
 
+We got confirmations to approve projects, though, so we could start
+working. We also started processing the recent requests, that need not
+confirmation.
 
address@hidden Approval Policies, GNU projects, Overview of the approval 
process, Projects approval
address@hidden Approval Requirements
+As soon as we finish processing this two categories of registrations,
+we plan to send another e-mail soon asking for everyone to confirm the
+status of their hosting request. The one-month limit also proved too
+optimistic, and will be postponed.
+
+This situation (lots of old requests) implies the following changes:
+
address@hidden
address@hidden
+Keep track of projects, new, confirmed, being approved, and
+approved. This is necessary because we would like to keep track of
+which projects were accepted in the post-crack slightly different
+Savannah architecture. We use a list that can be checked out using:
address@hidden
+-d:ext:@var{yourlogin}@@savannah.gnu.org:/cvsroot/administration co
+administration/lists/pending_projects_to_keep.txt}.
+
+You can also see it online at
address@hidden://savannah.gnu.org/@/cgi-bin/@/viewcvs/@/administration/@/administration/@/lists/@/pending_projects_to_keep.txt@/?rev=HEAD&content-type=text/vnd.viewcvs-markup}.
+
+The file is auto-documented. Submissions labelled ``Confirmed and
+Pending'' should be reviewed in priority.
+
+Make changes to this file as soon as possible. Among others, if you
+started reviewing a project, be sure to move it to the 'Being
+reviewed' section.
+
address@hidden
+Extra care should be taken before to ask a project to submitted
+again. First, this needs to manually remove the project from the
+database, since a cron job still needs auditing. Second, the project
+will be at the end of our pending projects queue, which will greatly
+increase our response delay. So we try to work out issues by mail,
+without re-registration as much as possible.
address@hidden itemize
+
+
+
address@hidden Approval Criteria, GNU projects, Overview of the approval 
process, Projects approval
address@hidden Approval Criteria
 
 Savannah does not host all kinds of software, and not even all kinds
 of free software.
@@ -1284,7 +1399,7 @@
 See the Free Software Definition at
 @uref{http://www.gnu.org/@/philosophy/@/free-sw.html}.
 
-Those URLs are required readings for any serious Savannah Hacker. Some
+Those URLs are required readings for any serious Savannah hacker. Some
 of us even think they should be taught in Computer Science lessons :)
 
 Keep in mind that a project released under the GNU GPL, be it hosted
@@ -1448,6 +1563,11 @@
 
 Ditto for Linux and GNU/Linux.
 
+Ditto for commercial software and proprietary software.
+
+If a project does not comply with this criteria only, you can approve
+it, but be sure to tell the user we would like to see these things to
+change.
 
 @node GIFs, Mirroring, Words to avoid, Approval Policies
 @subsection GIFs
@@ -1517,39 +1637,9 @@
 @node Rudy's Little HOWTO, Mathieu's Little HOWTO, GNU projects, Projects 
approval
 @section Rudy's Little HOWTO
 
address@hidden
-We have an emacs .el file for this, when using m-x sv_register_discad
-it asks for projectname and reason and pasts the command above in the
-buffer.  I start emacs locally, execute m-x eshell, and then ssh to
-savannah as root.  I can then use this el file on  the machine
-savannah.  I attached this file.
-
-In this file we have several functions, that we use for answer to user
-in a coherent way.  Also it saves us much typing.
-
-sv-approve                         sv-approve-as-nongnu
-sv-closing                         sv-closing-no-resubmit
-sv-confusion-commercial-and-proprietary
-sv-confusion-open-and-free         sv-opening
-sv-problem-details                 sv-problem-fsf-address
-sv-problem-gif                     sv-problem-gpl-info
-sv-problem-gpl-two-only            sv-problem-java
-sv-problem-lgpl-info               sv-problem-license-gplincompatible
-sv-problem-license-mpl-alike       sv-problem-license-truncated
-sv-problem-linux-vs-gnu            sv-problem-open-in-name
-sv-problem-tarball                 sv-problem-uses-gnu-name
-sv-reject-java-nonfree             sv-reject-nonfree-operating-system
-sv-reject-proprietary              sv-term-project-mark-as-deleted
-sv-term-project-pending-list
-sv-term-project-registration-discard
-sv-term-user-delete                sv-term-user-rename
-
-
-I won't discuss them, you should read them your selves.  And use them
-where appropriate.
-
-This is how I moderate a project:
+This HOWTO is being merge within the chapter.
 
address@hidden
 - I open the mailbox where all proejct registration emails go, and
   start replying.  Make sure to set the reply-to header to
   savannah-hackers mailinglist
@@ -1582,14 +1672,14 @@
 - check if the COPYING file is present and that it is intact
   (sv-project-license-truncated).  Make sure the new address of the
   FSF is being used.
-
-The .el file mentioned is present in Savane's distribution 
(@file{backend/gnu-specific/savannah.el}).
 @end verbatim
 
 
 @node Mathieu's Little HOWTO,  , Rudy's Little HOWTO, Projects approval
 @section Mathieu's Little HOWTO
 
+This HOWTO is being merge within the chapter.
+
 @verbatim
 (Add-on to general comments made in section 'Howto manage users')
 
@@ -1649,66 +1739,17 @@
 Do not reject the project if they propose to drop the non-free
 dependancy and work on it (really).   
 
-Java dependancy? Make sure it can work with libre java
-implementation. If you have no clue (ie if they did not said it could
-work) reject + ask to resubmit with more details about it.
-
-Also, pay attention to the name: do not accept project name too
-generic, do not accept confusing names (with GNU while it's not GNU,
-etc...). In that case, reject + ask to resubmit with another name.
-
-Finally, take a look at the tarball. First you should find GPL (or
-another license, the one chosen) headers in each source file, just
-like is is described at the end of the GPL text. Secondly, you should
-find a COPYING file with the complete license text. If it is missing,
-reject + ask to resubmit.
 If you find a trivial issue, and only that, like an error in FSF USA
 address, you can approve the project + send a note.
 
-=== APPRECIATED ITEMS ===
-
-We want our users to consider Linux as kernel and GNU/Linux as an
-OS. We want our users to talk about Free/Libre Software in first
-place, before open source. We do not want our users to consider that
-commercial software means proprietary.
-
-If they do not, do not refuse the project if everything else is fine,
-but send a note an approval saying we'd like these things to change.
-
 
 ********************* GET PRACTICAL *********************
 
   - Generate a GPG-key and try to sign mails you sent when rejecting
     project.
-  - Always included the list help (later it will be on the list
-    register) in your replies. 
   - It is a good habbit to do a rapid search on google with
     +site:mail.gna.org option to found out why the project was
     previously disregarded.
-  - In savane/savane/backend/gna-specific, you can find a lisp file
-    with canned answer (read the header of the file for details). It
-    is supposed to be very helpful to handle registration.
-    If you cannot use it, please try to include in your mails most of
-    the content of the canned responses.         
-
-=== APPROVE ===
-
-To approve a project, go on admin/approve pending projects page of the
-web interface. Select the project and use the form to set it as
-active. Once it is done, do not forget to click on the link at the
-bottom of the page saying "Send approval mail and trigger project
-creation". It does not only send mail but it also run site specific
-task, like projec-cvs mailing list at Gna!. Cronjob will built
-everything needed in the next hours.
-
-=== REJECT ===
-
-To reject a project, log on bart.gna.org (in the future, this
-procedure will probably change, by assigning a specific user account
-for that purpose). Then run 'sv_register_discard sysgroupname'. 
-
-Once it is done, send a mail to the project admin, CCed to help,
-explained your decision.
 
 @end verbatim