unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Re: 01/01: gnu: Add badass.
       [not found] ` <20180129215806.5F45C20512@vcs0.savannah.gnu.org>
@ 2018-01-29 23:09   ` Mark H Weaver
  2018-01-30  4:17     ` Leo Famulari
  2018-01-30  9:05     ` 01/01: gnu: Add badass ng0
  0 siblings, 2 replies; 9+ messages in thread
From: Mark H Weaver @ 2018-01-29 23:09 UTC (permalink / raw)
  To: ng0; +Cc: guix-devel

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: 01/01: gnu: Add badass.
  2018-01-29 23:09   ` 01/01: gnu: Add badass Mark H Weaver
@ 2018-01-30  4:17     ` Leo Famulari
  2018-01-31 13:53       ` Package inclusion criteria Ludovic Courtès
  2018-01-30  9:05     ` 01/01: gnu: Add badass ng0
  1 sibling, 1 reply; 9+ messages in thread
From: Leo Famulari @ 2018-01-30  4:17 UTC (permalink / raw)
  To: Mark H Weaver; +Cc: guix-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: 01/01: gnu: Add badass.
  2018-01-29 23:09   ` 01/01: gnu: Add badass Mark H Weaver
  2018-01-30  4:17     ` Leo Famulari
@ 2018-01-30  9:05     ` ng0
  2018-01-30  9:12       ` ng0
  1 sibling, 1 reply; 9+ messages in thread
From: ng0 @ 2018-01-30  9:05 UTC (permalink / raw)
  To: guix-devel

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/

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: 01/01: gnu: Add badass.
  2018-01-30  9:05     ` 01/01: gnu: Add badass ng0
@ 2018-01-30  9:12       ` ng0
  2018-01-31  3:54         ` Oleg Pykhalov
  0 siblings, 1 reply; 9+ messages in thread
From: ng0 @ 2018-01-30  9:12 UTC (permalink / raw)
  To: guix-devel

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/

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: 01/01: gnu: Add badass.
  2018-01-30  9:12       ` ng0
@ 2018-01-31  3:54         ` Oleg Pykhalov
  0 siblings, 0 replies; 9+ messages in thread
From: Oleg Pykhalov @ 2018-01-31  3:54 UTC (permalink / raw)
  To: ng0; +Cc: guix-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Package inclusion criteria
  2018-01-30  4:17     ` Leo Famulari
@ 2018-01-31 13:53       ` Ludovic Courtès
  2018-01-31 14:10         ` ng0
  0 siblings, 1 reply; 9+ messages in thread
From: Ludovic Courtès @ 2018-01-31 13:53 UTC (permalink / raw)
  To: Leo Famulari; +Cc: guix-devel

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Package inclusion criteria
  2018-01-31 13:53       ` Package inclusion criteria Ludovic Courtès
@ 2018-01-31 14:10         ` ng0
  2018-01-31 17:56           ` myglc2
  2018-01-31 23:48           ` Ludovic Courtès
  0 siblings, 2 replies; 9+ messages in thread
From: ng0 @ 2018-01-31 14:10 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel

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/

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Package inclusion criteria
  2018-01-31 14:10         ` ng0
@ 2018-01-31 17:56           ` myglc2
  2018-01-31 23:48           ` Ludovic Courtès
  1 sibling, 0 replies; 9+ messages in thread
From: myglc2 @ 2018-01-31 17:56 UTC (permalink / raw)
  To: ng0; +Cc: guix-devel

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?

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Package inclusion criteria
  2018-01-31 14:10         ` ng0
  2018-01-31 17:56           ` myglc2
@ 2018-01-31 23:48           ` Ludovic Courtès
  1 sibling, 0 replies; 9+ messages in thread
From: Ludovic Courtès @ 2018-01-31 23:48 UTC (permalink / raw)
  To: ng0; +Cc: guix-devel

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2018-01-31 23:48 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <20180129215805.7086.26926@vcs0.savannah.gnu.org>
     [not found] ` <20180129215806.5F45C20512@vcs0.savannah.gnu.org>
2018-01-29 23:09   ` 01/01: gnu: Add badass Mark H Weaver
2018-01-30  4:17     ` Leo Famulari
2018-01-31 13:53       ` Package inclusion criteria Ludovic Courtès
2018-01-31 14:10         ` ng0
2018-01-31 17:56           ` myglc2
2018-01-31 23:48           ` Ludovic Courtès
2018-01-30  9:05     ` 01/01: gnu: Add badass ng0
2018-01-30  9:12       ` ng0
2018-01-31  3:54         ` Oleg Pykhalov

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).