savannah-users
[Top][All Lists]
Advanced

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

Re: [Savannah-users] what are the usefulness criteria for submitted code


From: Assaf Gordon
Subject: Re: [Savannah-users] what are the usefulness criteria for submitted code?
Date: Fri, 3 Mar 2017 01:15:45 -0500

Hello,

If I may expand a bit:

Karl Berry wrote:
>> The policy has always been that Savannah
>> administrators can exercise judgement,
> [...]
>> I see that we have failed to state that on <url>;
>> we can work on that.

Judgement is implied (perhaps not clearly enough) in the supplementary page:
https://savannah.gnu.org/maintenance/HowToGetYourProjectApprovedQuickly/

"       • No storage or back-up-only project: we exist to help people develop 
software and technical documentation. Other hosting services offer storage 
space. We expect to be used primarily and not as a back-up, although we do not 
require all parts of the project to be hosted at Savannah.

        • We discourage submitting simplistic text-only projects, such as a 
single text or html file containing a list of urls. Such things are better 
maintained as straightforward web pages than incurring all the overhead of a 
full project at Savannah. Nonetheless, if you think your file is special and 
deserves its own dedicated project, we will consider your argument.
"

Checking these two items before project approval obviously require a judgement 
call by savannah admins.

Similarly rejected cases are "educational projects" (the kind that students get 
as assignment):
  https://savannah.gnu.org/task/?13639
I know GitHub is very popular as a teaching tool (or even assignment/submission 
mechanism),
and I wish them all the best - but savannah can't sustain that kind of usage.

And projects which look like a one-time experiment are also rejected:
 https://savannah.gnu.org/task/?13735


>> Savannah being a GNU project, you can appeal to
>> address@hidden, or ultimately rms, if you wish.
> 
> I hope you don't mean by that I shouldn't bother appealing to the Savannah
> project itself first. It makes no sense to me to go over your head when I
> can at least try to make a direct appeal to the very people who set the
> policy.

An even better idea: Join us and become a savannah hacker!
One place to start is here:
  https://savannah.gnu.org/maintenance/HowToBecomeASavannahHacker/

Or, when you formulate better approval criteria, work on the wiki:
  https://savannah.gnu.org/maintenance/HowToAdminThisWiki/


> I would like a chance to convince the Savannah project to replace this
> policy by a set of objective rejection criteria, which would hopefully
> accomplish the same purpose.

Sounds like a desirable thing to me. Even we can't eliminate the human factor 
completely,
at least we'll clarify some criteria.

If you go this way, please start a new discussion in address@hidden ,
and we'll continue it there.
It would be good to build upon the existing guidelines from here:
 https://savannah.gnu.org/maintenance/HowToGetYourProjectApprovedQuickly/
and also to examine past approval/rejections here:
 https://lists.gnu.org/archive/html/savannah-register-public/


> By the way, what is the purpose of this
> policy? I've seen a suggestion that this policy is needed because accepting
> everything would be basically too costly for a non-commercial
> volunteer-powered project like Savannah.

... and with extremely limited computational resources (such as disk space).
another problem is that due to the way savannah is built, projects identifiers
are global. Unlike other hosting services, we can't have two projects on 
savannah
with the same name.
Since we also never remove projects (regardless of how small they are),
unrestricted acceptance will not scale on savannah.

For example, this lead us recently to decide to reject new project with 3 
letters.
4 or more is the new requirements.

Is this policy perfect? of course not. and there are many stale / abandoned 
projects
on savannah. But we do what we can. Improvements are welcomed.

As a side-note, here are some guidance questions I had when I just started not 
too long ago:
 
https://lists.gnu.org/archive/html/savannah-hackers-public/2014-08/msg00056.html
 
https://lists.gnu.org/archive/html/savannah-hackers-public/2014-08/msg00025.html


> Is this an accurate enough
> description of the goal? Are there any other goals you would like to
> achieve with this policy? I asked this question before, but so far no
> answer was given by a member of the Savannah team. I do not for a second
> believe you people are going through so much trouble without a reason, so
> what is the purpose of this policy?

If we had the resources, I'm sure the savannah,GNU and FSF (who runs and 
operates
the servers) would be glad to support as many projects as possible.


> I hope you agree, this policy is fundamentally unfair and biased, more or
> less by definition.

Unfair to whom? for new users - perhaps.
But what about the FSF that needs to upkeep savannah's servers,
and savannah admins who are volunteers and maintain it on their own time?

Here's a different perspective:
Google-Code operated for 9 years, then google decided to close it, and they did.
Gitorious (another source-code hosting) ran from 2007 until 2015, then was 
bought by Gitlab and was shutdown.
gna.org (a sister-site for savannah, using very similar infrastructure) is 
being shutdown as well.

For comparison - GNU savannah has been up and running for 16 years (since 2001),
and is hosting code that dates back to 1986.
(almost) Every piece of code, every uploaded file, every mailing-list email that
passed through the savannah is still available, and at the same original URL it 
was first published.
Not a small feat considering how many years have gone through, and how many 
iterations of
hardward and software and people that worked on it.

It might sound unfair to new projects, but we must balance it with being unfair 
to existing projects
that want to know they will also have a stable, free platform for many years to 
come.

A somewhat conservative approach is useful to ensure we don't lose track of our 
long-term goals.

> If you could replace it by a set of objective rejection
> criteria which would accomplish the same purpose well enough, would you be
> willing to work towards that goal?

Yes, if we can find such objective criteria I think it'll be an improvement.

And I'll repeat Karl's message:
If we do and if we don't reach an agreement, you are still welcomed to write 
directly
to address@hidden or to rms himself.


> *Please*, even if you chose to ignore the rest of this message, please
> answer these 2 questions: what is the goal of this policy? would you be
> willing to replace it with an objective policy, if it could accomplish the
> same goal about as well?

I hope I answered these questions above, but I'm happy to discuss further.
A better place is to do so is address@hidden .

regards,
 - assaf





reply via email to

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