all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Jookia <166291@gmail.com>
To: Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de>
Cc: guix-devel@gnu.org, Guix-devel <guix-devel-bounces+me=tobias.gr@gnu.org>
Subject: Re: none
Date: Fri, 22 Jul 2016 22:50:14 +1000	[thread overview]
Message-ID: <20160722125014.GA13270@novena-choice-citizen> (raw)
In-Reply-To: <idjoa5puai9.fsf@bimsb-sys02.mdc-berlin.net>

On Fri, Jul 22, 2016 at 02:23:42PM +0200, Ricardo Wurmus wrote:
> Pjotr Prins <pjotr.public12@thebird.nl> 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.

  reply	other threads:[~2016-07-22 12:50 UTC|newest]

Thread overview: 104+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-21  1:39 (unknown) Unknown, Pjotr Prins
2016-07-21  1:42 ` [PATCH] gnu: Add elixir Pjotr Prins
2016-07-21 11:43   ` Ben Woodcroft
2016-07-21 12:00     ` Pjotr Prins
2016-07-22  5:26     ` Leo Famulari
2016-07-22 12:55       ` Ludovic Courtès
2016-07-22 14:12         ` Leo Famulari
2016-07-21 12:51 ` none Ludovic Courtès
2016-07-22  0:41   ` none Pjotr Prins
2016-07-22  2:06     ` none Pjotr Prins
2016-07-22  3:25       ` none Jookia
2016-07-22  3:48       ` none Leo Famulari
2016-07-22  4:48       ` none Tobias Geerinckx-Rice
2016-07-22 11:07         ` none Pjotr Prins
2016-07-22 12:23           ` none Ricardo Wurmus
2016-07-22 12:50             ` Jookia [this message]
2016-07-22 21:19               ` none Leo Famulari
2016-07-24  4:17                 ` none Jookia
2016-07-24  6:35                   ` none Leo Famulari
2016-07-24  7:47                     ` none Jookia
2016-07-24 16:52               ` none Christopher Allan Webber
2016-07-24 17:03                 ` none Andreas Enge
2016-07-22  8:15     ` none Roel Janssen
2016-07-22 14:07       ` none Leo Famulari
2016-07-22 14:15         ` none Vincent Legoll
2016-07-22 16:13       ` none Ludovic Courtès
2016-07-22 16:38         ` none myglc2
2016-07-23  7:03           ` none Tomáš Čech
2016-07-22 16:02     ` Review process Ludovic Courtès
2016-07-23  2:24       ` Pjotr Prins
2016-07-23  9:05         ` Alex Kost
2016-07-23  9:51           ` Mathieu Lirzin
2016-07-24  8:02             ` Alex Kost
2016-07-24 10:38               ` Mathieu Lirzin
2016-07-24 14:09               ` Ludovic Courtès
2016-07-24  3:30       ` A registry for distributed sources and binaries Pjotr Prins
2016-07-24  5:10         ` Tobias Geerinckx-Rice
2016-07-24  5:16           ` Pjotr Prins
2016-07-24  5:24         ` Pjotr Prins
2016-07-24  5:29         ` Mark H Weaver
2016-07-24  5:48           ` Jookia
2016-07-24  6:37             ` Tobias Geerinckx-Rice
2016-07-24  7:49               ` Jookia
2016-07-24 20:02             ` Ricardo Wurmus
2016-07-24  6:28           ` Tobias Geerinckx-Rice
2016-07-24  7:02             ` Pjotr Prins
2016-07-24  7:29           ` Leo Famulari
2016-07-24  7:41             ` Pjotr Prins
2016-07-24  9:50           ` Mathieu Lirzin
2016-07-24 22:46           ` Ludovic Courtès
2016-07-24 13:58         ` Andreas Enge
2016-07-24 15:21           ` Jookia
2016-07-24 15:58             ` Andreas Enge
2016-07-24 17:18             ` replying to a message of a mailing list you were not subscribed to Danny Milosavljevic
2016-07-24 17:25               ` Danny Milosavljevic
2016-07-25  5:38                 ` Ricardo Wurmus
2016-07-25  7:34                   ` icecat "mailto" handler does not work - and cannot be reconfigured by user Danny Milosavljevic
2020-10-13 13:23                     ` bug#24066: " Maxim Cournoyer
2020-10-16  7:12                     ` Brendan Tildesley
2020-10-26 16:39                     ` Jonathan Brielmaier
2016-07-24 18:50             ` A registry for distributed sources and binaries John Darrington
2016-07-25  9:14             ` Replying to bug reports Ludovic Courtès
2016-07-25  8:25           ` A registry for distributed sources and binaries Andy Wingo
2016-07-25 22:00             ` Reviewer assignment Ludovic Courtès
2016-07-24 20:35         ` A registry for distributed sources and binaries Ricardo Wurmus
2016-07-25  2:10           ` Pjotr Prins
2016-07-25  3:42             ` Tobias Geerinckx-Rice
2016-07-25  4:57               ` Pjotr Prins
2016-07-25  7:18           ` Tomáš Čech
2016-07-25  9:21           ` Ludovic Courtès
2016-07-26  3:40             ` Pjotr Prins
2016-07-26  3:45               ` Pjotr Prins
2016-07-25  6:13 ` [PATCH] Add Elixir (was: ) Ricardo Wurmus
2016-07-25  6:31   ` Pjotr Prins
2016-07-28  7:27     ` Ricardo Wurmus
2016-07-28  8:30       ` Vincent Legoll
2016-07-28 10:35       ` Pjotr Prins
2016-07-28 20:35         ` Ricardo Wurmus
2016-07-29  2:38           ` Pjotr Prins
2016-07-29  6:32             ` Vincent Legoll
2016-08-02  8:56             ` Ricardo Wurmus
2016-08-02 14:30               ` Pjotr Prins
2016-08-02  8:44     ` [PATCH] Add Elixir Ricardo Wurmus
2016-08-02 14:29       ` Pjotr Prins
2016-08-02 17:26       ` Ludovic Courtès
2016-08-02 21:25         ` Ricardo Wurmus
2016-08-03  4:41           ` Pjotr Prins
2016-08-09 11:18           ` Pjotr Prins
2016-08-09 11:58             ` Alex Sassmannshausen
  -- strict thread matches above, loose matches on Subject: below --
2016-07-23  9:15 none David Craven
2015-03-25 22:49 (unknown), Tomáš Čech
2015-03-26 21:22 ` none Ludovic Courtès
2015-03-26 21:52   ` none Tomáš Čech
2014-12-03 18:02 (unknown) Tomas Cech
2014-12-04 23:04 ` none Ludovic Courtès
2014-12-05  8:35   ` none Tomas Cech
2014-12-06 14:06     ` none Ludovic Courtès
2014-02-11 22:17 Gnunet-0.10.0 recipe Sree Harsha Totakura
2014-02-12 15:15 ` (unknown), Sree Harsha Totakura
2014-02-12 17:36   ` none Ludovic Courtès
2014-02-12 17:38     ` none Sree Harsha Totakura
2014-02-12 19:25     ` none Andreas Enge
2014-02-12 20:30       ` none Ludovic Courtès
2014-02-12 20:53         ` none Andreas Enge
2014-02-04 15:12 (unknown), John Darrington
2014-02-04 20:47 ` none Ludovic Courtès
2014-02-05 16:17   ` none Mark H Weaver
2014-02-05 17:38     ` none John Darrington
2014-02-05 18:35       ` none Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160722125014.GA13270@novena-choice-citizen \
    --to=166291@gmail.com \
    --cc=guix-devel-bounces+me=tobias.gr@gnu.org \
    --cc=guix-devel@gnu.org \
    --cc=ricardo.wurmus@mdc-berlin.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.