Re: none

[Christopher Allan Webber]

Jookia writes:

>> What makes things easier for me personally is to not worry about
>> urgency.  Nothing I do is really urgent.  If I need to provide a package
>> for someone at the institute I don’t wait for acceptance in Guix
>> upstream; I just push it to our own “guix-bimsb” repo, which is used via
>> GUIX_PACKAGE_PATH.  Eventually, changes are polished and get accepted
>> upstream; at that point I remove them from the external repo.  There is
>> no hurry and I can choose to take my time addressing issues mentioned in
>> reviews.  (One of my patches for “pam_limits” went through several major
>> revisions over a duration of half a year or so.  I’m a sloth.)
>
> Guuix uses a mailing list for development, like most GNU projects. Maybe this
> works for those, but Guix is trying to be hip and cool and fresh compared to
> most GNU projects which are stable and generally a pain to contribute to.
>
> On top of that, the maintainers can't even use the mailing list properly:
> Patches are lost, discussion doesn't happen, things are lost and it's hard for
> new users to join in. Who exactly benefits from this workflow compared to
> something web-based? Sure, maybe you could argue that the maintainers are best
> served with it, or that you personally are attuned to that. Fine, but let's 
> not
> pretend the mailing list isn't gruelling.

GNU MediaGoblin is "hip and cool" (or something) in that it uses a web
based issue tracker primarily.  (I guess it be hipper and cooler by
using something that integrated with git and had "web based pull
requests".)  Note that it hasn't saved us here.  There are times I fall
behind, and so do other contributors, and things get clogged up.  Often
I am envious these days of the speed at which Guix moves.  (A lot of the
slowness is related to me trying to advance standards work that helps
MediaGoblin in the long run, but that's an aside.)

Technological decisions can play a huge part... though even more so is
contributor bandwidth...

>> Aren’t you already doing this with your separate package set on Github?
>> In my opinion there is no need for an official project like that.  We
>> want most changes to be made to Guix directly.  Changes there are much
>> more likely to benefit the majority of users.
>
> This is the reason why I really dislike the current attitude of the community.
> You're building an operating system which by definition is meant to serve a 
> ton
> of different needs, building it slowly and not urgently at all, but then 
> arguing
> changes should be kept centralized for the benefit of all users and staging
> features should be pushed to whateve personal repositories we have.

Everyone else has said everything I'd like to say on this front mostly,
but I *do* think it's great that Guix is pure and has high standards.
That said, Guix probably could use some quasi-organized "guix-heresy"
external repositories that help people be "practical" where we can't.
(Heck, we won't be even able to advocate it, but the people who want it
will find it.)

To address Mark Weaver's points, yeah, that stuff will break
occasionally as in terms of internal Guix changes to the
codebase... that's the cost of doing it.

As one more aside, I'm glad to see this conversation happening but also
kind of bummed out... pretty much everyone on here I really admire.  I'm
confident things will pan out, if we listen to each other.

 - Chris