[Savannah-cvs] [125] no project removal, only mitigation

[karl]

Revision: 125
          
http://svn.sv.gnu.org/viewvc/?view=rev&root=administration&revision=125
Author:   karl
Date:     2014-12-09 16:44:10 +0000 (Tue, 09 Dec 2014)
Log Message:
-----------
no project removal, only mitigation

Modified Paths:
--------------
    trunk/sviki/RemovingProject.mdwn

Modified: trunk/sviki/RemovingProject.mdwn
===================================================================
--- trunk/sviki/RemovingProject.mdwn    2014-12-07 19:50:07 UTC (rev 124)
+++ trunk/sviki/RemovingProject.mdwn    2014-12-09 16:44:10 UTC (rev 125)
@@ -1,39 +1,26 @@
-Policies
---------
+Removing an existing project
+============================
 
--   If the request is because the project is hosted elsewhere, keeping
-    it creates confusion.
-    -   
<http://mail.gnu.org/archive/html/savannah-hackers/2003-05/msg00199.html>
+If a project has had nontrivial content of any sort created in it
+(source code, bug reports, etc.), we will not remove it from Savannah.
+Only essentially empty projects, or those approved by mistake, will be
+removed.
 
--   If the project was created by mistake, there is no problem removing
-    it.
-    -   
<http://mail.gnu.org/archive/html/savannah-hackers/2002-02/msg00385.html>
-    -   
<http://mail.gnu.org/archive/html/savannah-hackers/2002-05/msg00573.html>
+If developers wish to move continuing work off Savannah, various changes
+can be made in the Savannah project to minimize confusion, for example:
 
-### Otherwise
+- change the project description to say it's moved.
+- change the project status to Undefined.
+- make repositories read-only, via a support request.
 
--   <http://mail.gnu.org/archive/html/savannah-hackers/2002-12/msg00030.html>
--   Looks like SF had the same policy
-    -   
<http://mail.gnu.org/archive/html/adonthell-general/2002-05/msg00065.html>
+Administrative steps for removal
+--------------------------------
 
-Note: because of this policy we can't give complete control over to
-repository to admins. This is tedious, so I suggest that admins should
-generally be able to reset their project without our intervention.
-However, it would be good to back up to previous repository in such
-cases. We still should not give complete access to project members, nor
-direct write access when hooks are involved (we do not wish to grant any
-kind of local shell access).
-
-Doing it
---------
-
-### Steps to remove a project:
-
 -   Authentify the project administrator (eg. have him/her send a GPG
     signed confirmation)
 -   Mark it as deleted in Savane, so nobody change it
 -   Ask the project admin about deleting the mailing lists
--   run `infra/maintenance/delete_project.sh` projname
+-   run `infra/maintenance/delete_project.sh` PROJNAME  # probably doesn't work
     -   a backup of the project's sources will be put in
         `~/deleted-projects/`
     -   ??? mailing lists are still present in the database after