Re: 01/01: gnu: Add badass.

Re: 01/01: gnu: Add badass.

[Mark H Weaver]

Hi ng0,

> commit 57f9671d22bb4ee37962c31b9eed0ae50859398a
> Author: ng0 <ng0@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.

        Mark

Re: 01/01: gnu: Add badass.

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 1114 bytes --]

On Mon, Jan 29, 2018 at 06:09:16PM -0500, Mark H Weaver wrote:
> Hi ng0,
> 
> > commit 57f9671d22bb4ee37962c31b9eed0ae50859398a
> > Author: ng0 <ng0@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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Package inclusion criteria

[Ludovic Courtès]

Hello,

Leo Famulari <leo@famulari.name> skribis:

> On Mon, Jan 29, 2018 at 06:09:16PM -0500, Mark H Weaver wrote:
>> Hi ng0,
>> 
>> > commit 57f9671d22bb4ee37962c31b9eed0ae50859398a
>> > Author: ng0 <ng0@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.  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?

Ludo’.

Re: Package inclusion criteria

[ng0]

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

> Ludo’.
>
>

-- 
ng0 :: https://ea.n0.is
A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://ea.n0.is/keys/

Re: Package inclusion criteria

[myglc2]

On 01/31/2018 at 14:10 ng0@n0.is writes:

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

Re: Package inclusion criteria

[Ludovic Courtès]

ng0@n0.is skribis:

> On Wed, 31 Jan 2018, ludo@gnu.org (Ludovic Courtès) wrote:
>> Hello,

[...]

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

Like I wrote, these are quite unusual situations and special cases.  I
don’t expect to be able to have a policy document covering possible
cases.

(Linux is not included because it contains non-free software; that’s the
one inclusion criterion that’s very clear and unambiguous.)

Ludo’.

Re: 01/01: gnu: Add badass.

[ng0]

On Mon, 29 Jan 2018, Mark H Weaver <mhw@netris.org> wrote:
> Hi ng0,
>
>> commit 57f9671d22bb4ee37962c31b9eed0ae50859398a
>> Author: ng0 <ng0@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

So we do have Quality Standards for software that goes into Guix
now as in "you must be this tall to ride"? Didn't apply before
when other people sent in what I'd consider garbage.

I'd be okay with keeping it outside of Guix in my own repos, so
go ahead and drop it for random reasons.

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

-- 
ng0 :: https://ea.n0.is
A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://ea.n0.is/keys/

Re: 01/01: gnu: Add badass.

[ng0]

On Tue, 30 Jan 2018, ng0 <ng0@n0.is> wrote:
> On Mon, 29 Jan 2018, Mark H Weaver <mhw@netris.org> wrote:
>> Hi ng0,
>>
>>> commit 57f9671d22bb4ee37962c31b9eed0ae50859398a
>>> Author: ng0 <ng0@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
>
> So we do have Quality Standards for software that goes into Guix
> now as in "you must be this tall to ride"? Didn't apply before
> when other people sent in what I'd consider garbage.
>
> I'd be okay with keeping it outside of Guix in my own repos, so
> go ahead and drop it for random reasons.

Sorry, my reply was a bit too harsh. Here's another try:

I don't have any ability to predict the taste of people.
If we decline certain software entry into Guix, we should make it
clear.. case by case? standards?
Fyi I'm using this on github and other websites that make use of
the activity graph.

We do have software in our repository that I consider trash, so
it's always subjective.

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

-- 
ng0 :: https://ea.n0.is
A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://ea.n0.is/keys/

Re: 01/01: gnu: Add badass.

[Oleg Pykhalov]

[-- Attachment #1: Type: text/plain, Size: 1458 bytes --]

Hello,

ng0@n0.is writes:

>>> Why do you think this belongs in Guix?  Do you intend to use it
>>
>> So we do have Quality Standards for software that goes into Guix
>> now as in "you must be this tall to ride"? Didn't apply before
>> when other people sent in what I'd consider garbage.
>>
>> I'd be okay with keeping it outside of Guix in my own repos, so
>> go ahead and drop it for random reasons.
>
> Sorry, my reply was a bit too harsh. Here's another try:
>
> I don't have any ability to predict the taste of people.
> If we decline certain software entry into Guix, we should make it
> clear.. case by case? standards?
> Fyi I'm using this on github and other websites that make use of
> the activity graph.
>
> We do have software in our repository that I consider trash, so
> it's always subjective.
>
>>> 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.

If a program was written and distributed with a free or open license,
then it's not a garbage for a writer at least.  The purpose of usage
for everyone else could be different, maybe be a learning as example.

So, even if it's a simple script, but which somebody use and update, is
where a reason to block it?  After all it's not breaking anything.  :-)


Thanks,
Oleg.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]