Re: none

[Jookia]

On Fri, Jul 22, 2016 at 02:23:42PM +0200, Ricardo Wurmus wrote:
> Pjotr Prins <address@hidden> writes:
> 
> > On Fri, Jul 22, 2016 at 06:48:47AM +0200, Tobias Geerinckx-Rice wrote:
> >> In the spirit of (friendly) provocation, I'd nitpick on the term
> >> ‘purist views’ and suggest the word ‘standards’ instead. ;-)
> >
> > Alright. I concede ;)
> >
> >> But seriously: the code reviews? Most Free software projects don't
> >> do nearly enough. Also, most Free software projects su^W should.
> >
> > The number of contributors is not going up as fast as it should. I
> > have been quite exasparated with every package I submitted. Does that
> > mean I should stop packaging? Note that I actually like packaging, but
> > I feel mentally blocked to submit to the ML... Should we really leave
> > it to those that are more inclined to do the dance?

> I appreciate you sharing your experiences.

I've also quit Guix development because of these experiences, so forgive me for
my harsh words. See help-guix for my experiences. In general, I'm a bit sick of
this so I'm going to reiterate some of my concerns.

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

> I really don’t think we make it hard for people to contribute.  Projects
> using Github or similar platforms have a more complicated workflow
> (because you must work not only with your local clone but also your
> online fork, and you need to force push to make revisions to a pull
> request, etc).  Prior to Guix I had very little experience with a
> mail-based workflow, but I’ve come to really appreciate and prefer it
> over the alternatives.

It's a complicated setup in return for being able to track what's happening in
the project. If I were to ask, 'how many patches are pending review' right now
you'd have absolutely no idea.

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

> Hmm, an alternative is what you’ve suggested before: have reviewers
> accept more patches earlier.  Since we won’t budge on our standards this
> means that subpar patches take up more work, more time.  As it stands
> right now, we don’t have enough time / enough reviewers.  (I disagree
> with the claim that the number of contributors doesn’t grow quickly
> enough; we do have a problem with the number of reviewers.)

This isn't a software project, it's an operating system. At least until there's
a Guix and GuixSD repo split. Implying the issue that patches not being accepted
is due to subpar patches or high standards sounds good, but isn't true. A lot of
the issues are design-related and require discussion that can't be known in
advance by conributors since Guix is dictated by the maintainers' preferences.
To my knowledge there's no detailed list of what to do in absolutely every
situation involved in the complexity of packaging something, especially with how
new the project is.

> It should not be overlooked that some contributors started out with
> patch submissions that needed a lot of revisions who now provide us with
> extremely reliable contributions.  This relieves pressure from reviewers
> who can spend more time on other contributions.
> 
> For sustainable growth I think it is necessary that we “train”
> contributors by means of reviews.

Sorry, do you mean contributor as in packager or contributor as in general
devleoper that works on GuixSD's non-package features? How do we train people
doing the latter?

All in all, I say we have a repo for staging patches that work but aren't as
nice looking or implemented as well as they should be. If not part of Guix, then
as a branch/fork. It should not be up to Guix as to what features users get, but
instead the users based on whichever fork they're using.

> ~~ Ricardo

Jookia.