From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jookia <166291@gmail.com> Subject: Re: none Date: Fri, 22 Jul 2016 22:50:14 +1000 Message-ID: <20160722125014.GA13270@novena-choice-citizen> References: <579027b7.VHXjhpPxQC3AAmeY%pjotr.public12@email> <8760rznoh1.fsf@gnu.org> <20160722004130.GA10340@thebird.nl> <20160722020656.GA10533@thebird.nl> <20160722110739.GA12722@thebird.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:53641) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from <166291@gmail.com>) id 1bQZuZ-0004Wy-Qx for guix-devel@gnu.org; Fri, 22 Jul 2016 08:50:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from <166291@gmail.com>) id 1bQZuV-00083F-DQ for guix-devel@gnu.org; Fri, 22 Jul 2016 08:50:38 -0400 Content-Disposition: inline In-Reply-To: List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ricardo Wurmus Cc: guix-devel@gnu.org, Guix-devel On Fri, Jul 22, 2016 at 02:23:42PM +0200, Ricardo Wurmus wrote: > Pjotr Prins 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.