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

[Assaf Gordon]

On 08/15/2014 07:40 PM, Karl Berry wrote:
> I finally got to the end of the messages in this thread.
> My view FWIW follows ...
>
>      Should Savannah require projects to be at least build-able on
>      of the GNU systems.
>
> The answer is no.

I guess this closes the issue.
I'll try to revisit it in the future when I come up with better arguments.

> On the other hand, I completely agree that we should *encourage* people
> to use the free distros, and/or make it easier for evaluators wherever
> possible.  Changing the wiki page to strongly recommend giving exact
> package names for dependencies where possible, and (even more so) to
> check copyright statements for themselves, would be excellent
> improvements.  I'm sure plenty more could be done there, and/or on the
> submission page itself.  Let's continue on that path.

I'm reviewing few projects (for the first time), and that's exactly what I was 
thinking.

Here's what I've got:
http://files.housegordon.org/datamash/tmp/gnu_savannah_eval.sh

This script scans the files in the current directory, and checks the following:
1. Files with whitespaces
2. compiled binary files
3. long text files without recognizable copyright
4. long text files without recognizable license
5. plain-text license file
6. binary data files (e.g. png/jpg)
7. misuse of the term 'linux'

All these items are reported as suggestions. Obviously there's so much 
variation that
there's no sure-proof way to detect everything.

Items #1 and #2 are not strict requirement, but they make life easier (I hope 
you'll agree).

Item #3 - 'long' means more than 10 lines. 'recognizable' means a regex that 
can catch most common cases.

item #4 - 'recognizable' means fragments of the most common license (e.g 
GPL/BSD/X11) are found in the file.

Item #3 and #4 are cheap heuristics.
But I think it will catch most cases where either:
there's no copyright/license; or
there's a copy&pasted copyright and license (which is properly detected).

Item #5 - looks for the most common names for these files.
not a strict requirement, but makes life easier.

item #6 - if PNG/JPG/etc files are found, a warning is shown telling the 
developer to mention something about these files in the README file.

item #7 - some heuristics to catch the most common cases of misused 'linux' 
term.

There are *always* nuances, this file should only be used as a guidance for new 
submission.
But I hope it can help.

Examples, three recently submitted projects in Savannah with the output of this 
script:

## JNoteBook
https://savannah.gnu.org/task/?13287
http://files.housegordon.org/datamash/tmp/JNotebook_eval.txt

## RufasCube
https://savannah.gnu.org/task/?13292
http://files.housegordon.org/datamash/tmp/rufascube_eval.txt

## SciteProj
https://savannah.gnu.org/task/?13282
http://files.housegordon.org/datamash/tmp/sciteproj_git_eval.txt


And as a control, here's the same script output, on GNU Coreutils and GNU Grep:
http://files.housegordon.org/datamash/tmp/grep_git_eval.txt
http://files.housegordon.org/datamash/tmp/coreutils_git_eval.txt

There are clearly false-positives here, but often, these are small files (10-20 
lines) which really don't carry copyright or license.

If/when this script is hosted on Savannah, user can run it directly, as so:
    wget -qO- http://files.housegordon.org/datamash/tmp/gnu_savannah_eval.sh | 
sh

And we can require (=*highly* recommend) to at least attach the output of the 
script on the submitted project - this will show some effort from the submitter.


The script is portable enough to run on GNU/Linux [ :) ] and on FreeBSD 10.
It's commented and I hope it's understandable so that more checks could be 
added later.

Let me know what you think.


> Finally, I agree with Ineiev that the numerous nonfunctional projects
> simply are not a problem.  I would guess without looking that the
> majority of the ~3500 projects on Savannah are not functional and not
> being actively developed.  That doesn't mean they are consuming any
> notable resources beyond some disk space (we have plenty), and certainly
> doesn't mean they should be deleted.

"Delete" is a strong word... especially that on Savannah no piece free-software 
code should ever be deleted... (at least in theory?).
But how about some form of archiving? as-in, moving to some read-only place? 
locking the mailing-lists ?

But of course, this is another long-term discussion... perhaps for later.

-Assaf