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

[Ineiev]

On 08/14/2014 12:14 AM, Assaf Gordon wrote:
> The thread at [1] was informative and helpful for the project I'm
> reviewing now.
...
> But if I look at the state of things today,
> for barely functional or non-functional projects, there are many other
> hosting services out there.

There were enough hosting services out there when I filed that
submission. I don't think the situation is crucially different
in this respect today.

> Also, I think it is reasonable today to expect/require certain minimum
> useability from new projects.

Only if that minimum is virtually zero.

> GNU Savannah's resources are scarce - why burden it with projects that
> haven't exhibited even the minimal amount of functionality?

But they don't ask for food, do they?

> There are many stale CVS projects on Savannah (I'd guess more than a
> thousand).
> They no longer contribute anything to GNU Savannah as a concept or a
> community.

This doesn't seem quite correct to me.  I still use uisp; many
www.gnu.org translation teams are "stale", but it doesn't mean
they no longer contribute anything.

> What I'd like to require from new projects, and I (humbly) think it is
> very reasonable these days,
> is that a new project must be able to be build and work on one of the
> "sanctioned" GNU systems (Trisquel/gNewSense),
> and part of the submission form is to put the exact packages and
> commands required to build the project.

Let me see what this means... on my working machine, I usually
either install the packages when needed and forget about them,
or build them from their sources (and in many cases forget about them,
too).

It looks like I'd need a fresh installation (which may have multiple
options); probably it's too much.

> I think this will lead to several things:
> 1. It will "raise the bar" on submitted projects. Not that they are
> necessarily "better" (for what ever definition of "better),
> but it will force the developers to go through several verification
> steps, especially verifying (actually, almost proving) that the project
> can be built using Free Software.

I'm not sure it will; I can understand that it would raise it for
complicated projects, but when the submission is little bigger than
a "hello, world" in Python, the additional effort is infinitesimal.

> 2. It will make evaluation easier.
> If I can follow the build instructions on gNewSense and build the
> project, then by definition, the project's requirements are clear, and
> are Free-Software.

I don't think so: the evaluator would have to get the specific endorsed
distro, and the instructions may be complicated.

Currently, all this is unnecessary.

> 3. It will filter out "one shot" projects.
> There are several projects on GNU Savannah that have just one or two
> commits, then never been touched again.
> It's easy to submit a project when the only requirement is a proper
> copyright statement in a CPP file.
> If a developer is willing to invest time to properly package it and
> ensure it builds on Free-Software system, that it hints (but not
> guarantees, of course) that the developer is more serious about his
> project.

Again, if it's a "hello, world" CPP file, this would hardly filter
it out. usually the developers are really motivated when they
submit the package, and writing two more lines won't stop them,
even in case when their motivation will completely and irreversibly
evaporate the next day after the approval.

> 4. It will allow improving the "How To Get Your Project Approved
> Quickly" wiki page.
> Instead of general verbose instructions "Make sure your project runs
> primarily on a completely free OS" and " to make the approval process
> quicker, give us URLs to your dependencies, ideally with direct links to
> their licenses",
> we could write: "list the commands required to build to project on
> gNewSense or Trisquel".

Err.. this would discriminate against the users of Dynebolic and Dragora.

> No more need for a list of URLs for the evaluator to visit and verify.
...
> The submitter would list them list this:
>    # Standard gNewSense packages
>    sudo apt-get install sqlite3-dev qt4-dev
>    # Non-standard package PVBROWSER, GPL License:
>    # http://pvbrowser.de/pvbrowser/index.php?lang=en&menu=5
>    wget
> 
http://download.opensuse.org/repositories/home:/pvbrowser/xUbuntu_13.04/amd64/pvbrowser-devel_4.7.6-4.1_amd64.deb
>
>    sudo dpkg -i pvbrowser-devel_4.7.6-4.1_amd64.deb
>
> Then evaluating it would be much faster.

I can't see how it would help the evaluator (though it would
certainly make more work for the submitter): it's still
necessary to check whether the dependency is free.
and what if the instructions automatically install additional
software with dependencies?

I don't think Savannah evaluators should run so strict
checks for the dependencies; I believe they can typically rely
on what the developers say.