On 01/31/2018 at 14:10 n...@n0.is writes: > On Wed, 31 Jan 2018, l...@gnu.org (Ludovic Courtès) wrote: >> Hello, >> >> Leo Famulari <l...@famulari.name> skribis: >> >>> On Mon, Jan 29, 2018 at 06:09:16PM -0500, Mark H Weaver wrote: >>>> Hi ng0, >>>> >>>> > commit 57f9671d22bb4ee37962c31b9eed0ae50859398a >>>> > Author: ng0 <n...@n0.is> >>>> > 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?
