From mboxrd@z Thu Jan 1 00:00:00 1970 From: myglc2@gmail.com Subject: Re: Package inclusion criteria Date: Wed, 31 Jan 2018 12:56:27 -0500 Message-ID: <86a7wt7vzo.fsf@gmail.com> References: <20180129215805.7086.26926@vcs0.savannah.gnu.org> <20180129215806.5F45C20512@vcs0.savannah.gnu.org> <87372ob6ub.fsf@netris.org> <20180130041713.GB7677@jasmine.lan> <87607it9r5.fsf_-_@gnu.org> <87efm6xgos.fsf@abyayala.i-did-not-set--mail-host-address--so-tickle-me> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:49302) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1egwcb-0005sg-Qu for guix-devel@gnu.org; Wed, 31 Jan 2018 12:56:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1egwcY-0002KH-OL for guix-devel@gnu.org; Wed, 31 Jan 2018 12:56:33 -0500 In-Reply-To: <87efm6xgos.fsf@abyayala.i-did-not-set--mail-host-address--so-tickle-me> (ng0@n0.is's message of "Wed, 31 Jan 2018 14:10:11 +0000") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: ng0@n0.is Cc: guix-devel@gnu.org On 01/31/2018 at 14:10 ng0@n0.is writes: > On Wed, 31 Jan 2018, ludo@gnu.org (Ludovic Court=C3=A8s) wrote: >> Hello, >> >> Leo Famulari skribis: >> >>> On Mon, Jan 29, 2018 at 06:09:16PM -0500, Mark H Weaver wrote: >>>> Hi ng0, >>>>=20 >>>> > commit 57f9671d22bb4ee37962c31b9eed0ae50859398a >>>> > Author: ng0 >>>> > 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, essentia= lly >>>> > +hacking the gamification of contribution graphs on platforms such as >>>> > +Github or Gitlab.") >>>>=20 >>>> 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? >>>>=20 >>>> 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=E2=80=99s concerns, though I don=E2=80=99t have a = strong opinion >> on this particular package (I find it both =E2=80=9Cweird=E2=80=9D and = =E2=80=9Camusing=E2=80=9D; 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=E2=80=99d rather not include in Guix proper for various reas= ons. >> >> 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=E2=80=99s hard to antici= pate >> them; I suspect it=E2=80=99s 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?