From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Re: none Date: Fri, 22 Jul 2016 14:23:42 +0200 Message-ID: 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: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:48561) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bQZUy-0005xH-3l for guix-devel@gnu.org; Fri, 22 Jul 2016 08:24:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bQZUv-00033B-Sd for guix-devel@gnu.org; Fri, 22 Jul 2016 08:24:11 -0400 In-Reply-To: <20160722110739.GA12722@thebird.nl> 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: Pjotr Prins Cc: guix-devel@gnu.org, Guix-devel 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 >> =E2=80=98purist views=E2=80=99 and suggest the word =E2=80=98standards= =E2=80=99 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=E2=80=99t wait for acceptance in Guix upstream; I just push it to our own =E2=80=9Cguix-bimsb=E2=80=9D repo, wh= ich 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 =E2=80=9Cpam_limits=E2=80=9D went throug= h several major revisions over a duration of half a year or so. I=E2=80=99m a sloth.) I really don=E2=80=99t think we make it hard for people to contribute. P= rojects 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=E2=80=99ve come to really appreciate and prefe= r 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=E2=80=99t you already doing this with your separate package set on G= ithub? 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=E2=80=99ve suggested before: have reviewe= rs accept more patches earlier. Since we won=E2=80=99t budge on our standar= ds this means that subpar patches take up more work, more time. As it stands right now, we don=E2=80=99t have enough time / enough reviewers. (I disa= gree with the claim that the number of contributors doesn=E2=80=99t grow quick= ly 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 =E2=80=9Ctrain=E2=80= =9D contributors by means of reviews. ~~ Ricardo