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

[Assaf Gordon]

On 08/14/2014 06:03 AM, Ineiev wrote:
> 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.

If you are referring to 'stribog', submitted in 2006, then I think differently:
Until ~2008, I believe the two most popular services were SourceForge and 
BerliOS,
followed by several smaller services (such as Savannah).

Since ~2008, GitHub/BitBucket/Gitorious and several others have shown up and 
made things much easier for
users to host projects.
With the emergence of "cloud services" (as much as FSF/GNU resent this misleading term, it still exists) and multiple 
self-hosting projects (e.g. "gitolite" / "gitlabs") and even simple "gitweb" / "hg serve" / 
"bzr loggerhead" -
code hosting today is much more approachable than in the past.

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

Perhaps "useability" is a wrong choice of word.
I guess any term I'd choose would be too vague, but I'll try to come up with 
something.

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

I think the opposite - they ask for a lot of "food", as in resources.
Submission requires evaluation - time from volunteers.
During development, all of savannah's resources are used 
(vcs/web/mailing-lists/etc) meaning bandwidth and CPU and disk storage.
Sometimes it also requires support from Savannah maintainers.
When a project goes "stale", Savannah's "promise" is to keep everything about that 
project available forever (source code, VCS repository, bugs, tasks, mailing-lists) - this 
"forever" is expensive in terms of administration.

And I would argue this:
If a project is active, or maintained, and is being used to a reasonable degree (and 
please understand that I haven't exactly defined what "reasonable" is, because 
I don't want to nitpick), than investing all these resources is worthwhile.
It promotes Free-Software, improves users' productivity, etc.

If a project is "stale", then these resources are not spent wisely on improving 
Free-Software.

Now I'd like to emphasize again that I'm aware that there are nuances:
No commits does not translate immediately to "stale".
An example of that would be "gperf" which was officially unmaintained until 
just now.
But even with gperf, there are minor commits until 2 years ago, and there are 
few discussions with relevant replies in the mailing lists (as opposed to just 
spam).

"Stale" projects that I'm referring to have not been touched by anyone in many 
years, and even then there's room to decide if they simply do not require updates but are 
still usable, or completely abandoned.

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

I'm working on compiling hard data
Hope to have it soon.

Regarding "uisp" - that's a good test case for me, and I'll learn from it.
I would have called it "stale".

But looking at the  project, the last commit was in ~2005, the last 
mailing-list reply from 2013
claims this to be unmaintained, and pointing to a superseding project
(which is also on Savannah, and has been updated as recently as 5 months ago):
http://lists.nongnu.org/archive/html/uisp-dev/2011-08/msg00001.html


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

This is a technical issue with is secondary to the primary issue:
Should Savannah require projects to be at least build-able on of the GNU 
systems.

I'm certain we can find a way to have a good test/build system,
there are many possible technical solutions.

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

If it's infinitesimal, then there shouldn't be a problem asking the submitter 
to add this information.

But I would again argue that the point is not to torment the submitter - it is 
to improve the quality of software submitted to Savannah.

In practice, I think most submissions have been more than "hello world".
There are always nuances and exceptions, but I think it will help most 
submissions.

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

I did not mean "gNewSense" literally, but as an example for the sanctioned free 
systems.

Again, my point is to require more of the submitter, to ease the evaluation 
*and* the usage for users.
Asking the submitter to list the required packages for the systems will make it 
easier.

It doesn't mean you have to install the exact system, it means the submitter 
should take his time (could be very little time) and
find the right packages, for the most common flavors of distributions 
(DEB/RPM/slackware/etc).
Doing this will help, even if the evaluator uses a different system, because a 
standard package in one distribution is usually easy to find in another, with 
similar enough names.

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

I don't want to stop them or filter projects.
On the contrary: I want to encourage them to submitter better projects.

If the developers are really motivated, let them please take 10 more minutes 
and detail useful installation instructions.
If they are not motivated enough to do so - then that's the cases I want to 
"flag".
Again, there are nuances, it's not black-or-white. But in the general common 
case,  I think this will improve submissions.


>  > 4. It will allow improving the "How To Get Your Project Approved
>  > Quickly" wiki page.
>  > 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.

I feel this is being taken too literally.
What I meant is we should as submitters to list installation for the common 
sanctioned GNU systems.
DEB-based (which Dynebolic is one of), RPM-based, SLackware, etc.

It will not cover all systems or all cases, but will cover most.

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

Requiring that a submitted project can be build will make more work for the 
submitter and the evaluator.
I do not claim otherwise.
I do think this extra work is worthwhile.
And if you agree this extra work is worthwhile, then requiring better 
installation instructions will make it slightly harder for the submitter and 
slightly easier for the reviewer (and the users).
If you don't agree, then there's no added value in requiring exact installation 
instructions.

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

My "tongue in cheek" response would be that If evaluators believe the 
submitter, there's no need in evaluation :)
The submitter checked the boxses "All my files include valid copyright notices" and 
"All my files include a license header"
and "Origin and license of media files is specified" and "My tarball includes a copy 
of the license",
when they submitted the project ...


But again,
all the above the technical issues, secondary to the main question:
Should Savannah require projects to be at least build-able on of the GNU 
systems.

If there's agreement, we can find the optimal way to draft the requirements.
If there's no agreement, then the details don't matter.

Regards,
 -Assaf