Re: Package inclusion criteria

[myglc2]

On 01/31/2018 at 14:10 address@hidden writes:

> On Wed, 31 Jan 2018, address@hidden (Ludovic Courtès) wrote:
>> Hello,
>>
>> Leo Famulari <address@hidden> skribis:
>>
>>> On Mon, Jan 29, 2018 at 06:09:16PM -0500, Mark H Weaver wrote:
>>>> Hi ng0,
>>>> 
>>>> > commit 57f9671d22bb4ee37962c31b9eed0ae50859398a
>>>> > Author: ng0 <address@hidden>
>>>> > Date:   Wed Jan 17 22:42:55 2018 +0000
>>>> >
>>>> >     gnu: Add badass.
>>>> [...]
>>>> > +  (package
>>>> > +    (name "badass")
>>>> > +    (version (git-version "0.0" revision commit))
>>>> [...]
>>>> > +    (synopsis "Hacking contribution graphs in git")
>>>> > +    (description
>>>> > +     "Badass generates false commits for a range of dates, essentially
>>>> > +hacking the gamification of contribution graphs on platforms such as
>>>> > +Github or Gitlab.")
>>>> 
>>>> Why do you think this belongs in Guix?  Do you intend to use it
>>>> yourself, or do you have reason to believe that Guix users would want
>>>> this?
>>>> 
>>>> There's a lot of garbage out there.  Guix doesn't need to include every
>>>> script that someone uploaded to github.  Frankly, I'm embarrassed to
>>>> have a package like this in Guix.
>>>
>>> As the committer, I thought of this as an amusing toy, and we do have a
>>> couple of those.
>>>
>>> But if people would rather we not distribute it, I won't object.
>>
>> I can understand Mark’s concerns, though I don’t have a strong opinion
>> on this particular package (I find it both “weird” and “amusing”; it
>> reflects on how people use those Git services.)
>>
>> The only formal acceptance criterion for packages in Guix is that it
>> must be free software and FSDG-compatible.  However, there might be
>> software we’d rather not include in Guix proper for various reasons.
>>
>> One example we discussed recently is a package that allowed users to
>> exploit specific security vulnerabilities, IIRC, and at the time we
>> chose not to include it.

ISTM if we "publish" the rationale for excluding a package this would
capture it for posterity and potentially be useful to our users.

>> I suspect there are other situations where we
>> might be inclined to reject the package, but it’s hard to anticipate
>> them; I suspect it’s going to be rare, though.
>>
>> Thoughts?
>
> I think we should do the following:
>
> * list examples of what has been previously rejected or dropped,
>   there we can list LISPF4 (accepted, never worked, code to be
>   considered not really copyright worthy, dropped), the recent
>   black/greyhat / PoC package I've sent, software not aligned
>   with the guidelines of Guix (for example linux),...
>   Probably best in full sentences "Software packages which are
>   intend to be used by professionals bla bla bla ..."
> * include a way for exceptions..
>   the list we provide should give a clue about
>   what's possible and what not, but we should decide per
>   case, so that exceptions can be discussed.

Would it be feasible to capture such info in a "unpackage stub" that
make packaage appear in our package lists along with the rational for
why is is not in guix?