savannah-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Sylvain Beucler
Subject: [Savannah-cvs] administration/docs/hacking_savannah hacking_sa...
Date: Thu, 12 Aug 2004 15:03:49 -0400

CVSROOT:        /cvsroot/administration
Module name:    administration
Branch:         
Changes by:     Sylvain Beucler <address@hidden>        04/08/12 18:59:47

Modified files:
        docs/hacking_savannah: hacking_savannah.texi 

Log message:
        Added Yeupou's own approval howto (to be merged)

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

Patches:
Index: administration/docs/hacking_savannah/hacking_savannah.texi
diff -u administration/docs/hacking_savannah/hacking_savannah.texi:1.21 
administration/docs/hacking_savannah/hacking_savannah.texi:1.22
--- administration/docs/hacking_savannah/hacking_savannah.texi:1.21     Thu Aug 
12 18:18:47 2004
+++ administration/docs/hacking_savannah/hacking_savannah.texi  Thu Aug 12 
18:59:46 2004
@@ -1,5 +1,5 @@
 \input texinfo   @c -*-texinfo-*-
address@hidden $Id: hacking_savannah.texi,v 1.21 2004/08/12 18:18:47 Beuc Exp $
address@hidden $Id: hacking_savannah.texi,v 1.22 2004/08/12 18:59:46 Beuc Exp $
 @comment %**start of header
 @setfilename hacking_savannah.info
 @include version.texi
@@ -971,7 +971,7 @@
 Pending'' should be reviewed in priority.
 
 
address@hidden Rudy's Little Howto
address@hidden Rudy's Little HOWTO
 
 @verbatim
 Log on to the savannah website, people who are part of the savannah
@@ -1119,6 +1119,139 @@
 (sylvain)
 
 
address@hidden Mathieu's Little HOWTO
+
address@hidden
+How admins should handle project approval? 
+
+(Add-on to general comments made in section 'Howto manage users')
+
+We assume that you are familiar enough with common free software
+licences. The reference is
+http://www.gnu.org/philosophy/license-list.html , you should always
+check this page in doubt.
+
+
+********************* THEORY ***********************
+
+Project rejection is not definitive. When we reject a project, it is
+for a specific list of reasons. If the reasons are no longer valid, we
+can accept a project. 
+
+Many project will be rejected once just because their author will not
+pay enough attention to the registration process and will not provide
+enough information. 
+
+Since we'd like to avoid rejecting the same project 30 times, when
+you're rejection a project, list in your mail all the problems you
+find, not only the first one.
+
+By experience, we can tell that it is a real pain in the ass to check
+after approval whether some task will be done or not. So the policy is
+to reject project that do not fulfill requirement until they do. 
+
+If an admin made a mistake when approving a project, we count on him
+to take care of the resulting troubles. He will have to take the
+necessary time to make sure the project approved conform to Gna! rules
+ASAP. 
+
+
+
+=== PRIMARY REQUIRED ITEMS ===
+
+First take a look at the description and tarball. 
+
+Description too vague, that is not enough for you to understand what
+is about?
+Reject + ask to resubmit.
+
+No tarball while it is obvious that the project is not at design
+stage, while there is no mention that the project is at design stage?
+Reject + ask to resubmit.
+
+Then take a look at the license. Non-free? Reject, and ask to resubmit
+if they're willing to change the license. 
+Non GPL-compatible? Reject and ask to resubmit if they're willing to
+change the license (recommend mBSD or LGPL for BSD original)
+
+=== SECONDARY REQUIRED ITEMS ===
+
+If you get here, the package met the primary requirements.
+
+Now Take a look at the dependencies. 
+
+Non-free dependancies? Reject if the dependency is mandatory, provides
+stuff making proprietary software usage a plus technically speaking,
+but try to incitate the developers to decide to drop the
+dependency. 
+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.
+
address@hidden verbatim
+
+
+
 @section GNU projects
 
 Note that we do not accept GNU projects directly. First, they are
@@ -1128,10 +1261,14 @@
 evaluation team accepts the project as GNU.
 
 Also, we have this FAQ entry:
-http://savannah.gnu.org/faq/?question=What_does_it_mean_to_become_a_GNU_package.txt
address@hidden://savannah.gnu.org/@/faq/@/?question=What_does_it_mean_to_become_a_GNU_package.txt}
+Canonical URL to refer to this information is:
address@hidden://www.gnu.org/evaluation/evaluation.html}
+(I'll make the FAQ a rediction soon)
 
 (sylvain)
 
+
 @section Web Server Syndication
 
 Content for pages on www.gnu.org and www.nongnu.org is controlled by




reply via email to

[Prev in Thread] Current Thread [Next in Thread]