Re: none

[Ricardo Wurmus]

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 may be wrong but to me this comes down to familiarity with Git or
with having a convenient workflow.  I work on many packages and core
changes at the same time in different branches and not having to think
about Git makes this a lot easier.  Rarely ever do I feel that a
suggested change is inconvenient because I can just add a new tmp
commit, interactively rebase to reorder and squash commits, and produce
a new patches.  All of that in separate branches so that I can continue
work on other things without any impact.

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

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.

>> As long as it's not a fork in any way: yes please!
>
> We should consider a separate project that is aligned with trunk. I
> don't want to divert, but to add to both.

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.

> I am not looking forward to having a separate project, but I don't see
> much of an alternative. There will be a fear that actualy
> contributions to GNU Guix can go down - there is that risk - but my
> aim is to get more acceptance and contributors and eventually we all
> gain. I am not worried about QA. Work can be self correcting - we
> see that a lot.

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

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.

~~ Ricardo