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

[Sylvain Beucler]

CVSROOT:        /cvsroot/administration
Module name:    administration
Branch:         
Changes by:     Sylvain Beucler <address@hidden>        04/11/03 21:03:16

Modified files:
        docs/hacking_savannah: hacking_savannah.texi 

Log message:
        Removed section about "current situation" (outdated)
        Added a bit of general text about license notices in the approval 
chapter.

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

Patches:
Index: administration/docs/hacking_savannah/hacking_savannah.texi
diff -u administration/docs/hacking_savannah/hacking_savannah.texi:1.66 
administration/docs/hacking_savannah/hacking_savannah.texi:1.67
--- administration/docs/hacking_savannah/hacking_savannah.texi:1.66     Mon Nov 
 1 16:47:09 2004
+++ administration/docs/hacking_savannah/hacking_savannah.texi  Wed Nov  3 
21:03:15 2004
@@ -1,5 +1,5 @@
 \input texinfo   @c -*-texinfo-*-
address@hidden $Id: hacking_savannah.texi,v 1.66 2004/11/01 16:47:09 Beuc Exp $
address@hidden $Id: hacking_savannah.texi,v 1.67 2004/11/03 21:03:15 Beuc Exp $
 @comment %**start of header
 @setfilename hacking_savannah.info
 @include version.texi
@@ -2509,107 +2509,6 @@
 Savannah hackers (via e-mail or IRC), so he can review your review.
 
 
address@hidden The current situation, Approval Criteria, Approving projects, 
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.
-
-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
-
-
-
 @node Approval Criteria, GNU projects, The current situation, Projects approval
 @section Approval Criteria
 
@@ -2788,6 +2687,13 @@
 In addition, a full copy of the license should be added to the
 package, preferably in a file named @file{COPYING}.
 
+The goal is IMHO to precisely point the users what is wrong, providing
+an URL for exhaustive information. Providing an URL should not replace
+a per-case explanation. We do not provide the notices explicitely
+though - they have to find themselves how to write them, else we would
+have taught nothing to them.
+
+
 @node Kind of software, Words to avoid, Legal Notices, Approval Criteria
 @subsection Kind of software