Re: A registry for distributed sources and binaries

[Jookia]

On Sun, Jul 24, 2016 at 03:58:28PM +0200, Andreas Enge wrote:
> One of my main concerns with your suggestion (besides the technical one) is
> that I do not think it lowers the barrier to entry, but it diverts the
> efforts. With package repositories full of packages around, where a half-
> baked recipe can simply be dropped for the world to use, what would be the
> incentive of contributing back into the main project?

It's starting to sound like this is a self-preservation tactic to make Guix a
single project that aims for a target audience with certain quality rather than
an ecosystem with many variants. Is it really a bad thing if that happens? Maybe
for the project, but not for the people or world at large.

> My impression is that it is extraordinarily easy to contribute to Guix:
> Anybody can post packages to the mailing list, and after a bit of back
> and forth, they are usually added. No copyright assignment, no need to
> become a "Guix maintainer". Making it even easier essentially means dropping
> quality control. Then packages of bad quality floating around Guix would
> mean bad publicity.

Okay, I'll bite: Contributing at all to any formal project gives me sickness,
worries and the feeling of panic. IRC with certain people gives me the same
feelings. It's especially worse with projects where it uses Git and mailing
lists. There's so many places things can go wrong, from misconfiguring your mail
client, to accidentally only single replying, to sending updated patches and not
knowing how to explain the differences since you're sending a patch.

Even worse, if I want to reply to an issue on a mailing list that I'm not
subscribed to, it's difficult. I still haven't figured it out, maybe you can go
to the archive and download an mbox and look at the reference and ask your mail
client to reply to it? I don't know.

An issue tracker that you can reply to by the web would be much much better,
because there's less things to go wrong and less ways to be shamed for. I've
suggested this many times and the only responses I've heard are 'no' and 'let me
tell you how easy you can use mailing lists', so I give up.

> Is this the elephant in the room? Besides quality control, which is
> necessary to make a distribution with thousands of packages maintainable
> by just a few people, our only "restrictive" opinion is supporting only
> free software - anything that is free software can go in. But this is
> central to the project and a point where no compromises can be made.
> Our goal is to support free software and only free software, which is
> a promise to our users, supporters and ourselves.

It doesn't have to be nonfree software, it could be offensive/controversial
content (just think about whatever offends you the most then picture it in
software form). The point is that a single Guix isn't going to please everyone,
so it'd be nice to have a way to have branches and communication rather than
branches and walls. Is it too much to ask for this?

To the contray, the elephant in the room (at least in this thread) seems to be
that Guix also can be used to build an OS: GuixSD. Perhaps it'd be a wise idea
to mark GuixSD as 'maintainer-only' until there's enough reviewers to have the
public contribute to it? Then we can go back to arguing about packages.

Look, I really like Guix- that's why I'm so upset and hurt over this. I'm not
trying to troll or provoke arguments, that's just frustration. But when I've
seen people complaining about their system broken with bugs that I've had fixed
*months ago* and tried to upstream to no avail, where am I supposed to go from
here? Short of a fork, there's absolutely nothing I can do to even get people to
TRY changes and use that to iron out bugs. This isn't the first GNU/FSF
project that I've attempted to contribute to after seeing contributions were
needed then have those contributions ignored/forgotten about. There's always
reasons, but it's painful each time.

I think I'm done for now. No amount of writing has even started a discussion on
how to fix things, only that things aren't broken.

> Andreas

Jookia.