[Top][All Lists]

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

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

From: Assaf Gordon
Subject: Re: [Savannah-hackers-public] requirements of a new project in GNU Savannah
Date: Fri, 15 Aug 2014 22:39:14 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0

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 

Here's what I've got:

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' 

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

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

## JNoteBook

## RufasCube

## SciteProj

And as a control, here's the same script output, on GNU Coreutils and GNU Grep:

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- | 

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.


reply via email to

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