Re: [Savannah-hackers-public] Decommissioning inactive projects / users?

[John Sullivan]

k...@freefriends.org (Karl Berry) writes:

 old accounts vulnerable to hijacking

 I suppose so.

 Or instead of removing accounts, they could be locked after some
 number of years
 
 Locking makes sense to me after X years, especially on accounts meeting
 the criteria Sylvain checked (= completely unused).

 and unanswered email pings. 

 I would never go to the trouble of pinging people about sv accounts.

I wouldn't suggest anyone do it manually. 

-john

-- 
John Sullivan | Executive Director, Free Software Foundation
GPG Key: 61A0963B | http://status.fsf.org/johns | http://fsf.org/blogs/RSS

Do you use free software? Donate to join the FSF and support freedom at
http://www.fsf.org/register_form?referrer=8096.

Re: [Savannah-hackers-public] requirements of a new project in GNU Savannah

[Karl Berry]

1. DirEvent/DirCond:

Approval of this one has to wait for another reason: it needs to be
dubbed GNU (by rms).  That process is separate from Savannah.  I'm
working on it.

2. SciTE-proj
https://savannah.gnu.org/task/?13282
http://files.housegordon.org/gnu_eval1/SciTE-proj.2014-08-18-183834.html

The three image files are properly mentioned in the README file
(checked manually, this isn't shown in the report).

If you've also looked at it manually and don't see any problems,
go ahead and approve it as far as I'm concerned.  I trust you.

3. JNoteBook
https://savannah.gnu.org/task/?13287
http://files.housegordon.org/gnu_eval1/JNoteBook.2014-08-18-183836.html
One source code file is GPL'd.
Four image files just need to be mentioned in README (or perhaps
this is not even a requirement?)

It is a requirement, but I think what we have done in practice when such
a small thing is all that is left is to approve without requiring them
to go through one more submission iteration; just tell them to please do
the README thing when it's approved.

http://files.housegordon.org/gnu_eval1/RufasGate.2014-08-18-183836.html

Looks like a prefix //-- may be confusing things.  Maybe the code
could somehow detect/ignore any arbitrary prefix?

Also, unless those .so's are generated from source within the project
(didn't check), we certainly can't host them.  Binaries are only ok if
complete sources are available, of course.

http://files.housegordon.org/gnu_eval1/GNU-coreutils.2014-08-18-183813.html

I would suggest adding one more list:
  Files without either copyright or license statement
and then reduce the Files without copyright and Files without license
categories accordingly.  It's very common that if a file lacks one, it
lacks the other, so it's easier to understand if that is reflected in
the script output.

On another front, the output says:
  A recognizable copyright statement in this script should be of form:
  Copyright (C) YEAR NAME (email)

The should is not correct.  Neither the (C) nor the (email) are
required, or even necessarily recommended.  Also there is usually more
than one year involved.  So maybe:

  A copyright statement should be of the form:
  Copyright YEARS NAME
  An optional (C) and/or contact addresses can be added if you wish.


Enough for today ...

Thanks,
K