From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Re: Guix package incubator (later a channel) Date: Tue, 07 Feb 2017 20:38:58 +0100 Message-ID: <87shnplrjh.fsf@elephly.net> References: <20170206190923.GA3592@mail.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]:46018) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cbBbd-0004rv-Ux for guix-devel@gnu.org; Tue, 07 Feb 2017 14:39:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cbBbc-0002eI-Cv for guix-devel@gnu.org; Tue, 07 Feb 2017 14:39:14 -0500 In-reply-to: <20170206190923.GA3592@mail.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 Hi Pjotr, during the panel on the Future of Guix we all agreed that there is a need to lower the barrier to entry for package submissions to Guix, so it is good to start a discussion about actionable steps we can take to make this happen. > After yesterday's FOSDEM discussion I propose to set up a 'Guix > incubator' git tree using Gitlab. The master branch will track the > main Guix master but project can run on forked trees and branches. The > idea is to have patches prepared by new committers or by people who > simply prefer to use a web-based git environment. Each of these trees > can become a guix channel - once we have channels to support that. During the panel we had a question from the audience about alternative tools, e.g. to allow a workflow that is not email-based. While I can understand the desire to use a workflow that you may be used to from other projects (this goes both ways) there is a danger in establishing alternatives to the channels on which we accept contributions. At this point in the evolution of Guix we have many more contributors than people who can mentor the contributors, polish their patches for inclusion upstream, or provide constructive comments. Having so many people contribute is great! But it also means that we need to be careful with our limited number of mentors. I see two possible outcomes of establishing an additional “incubator” repository: it might fragment our review community as some people will try to upstream incubator patches and others handle mailing list patches; another outcome is that the incubator never gets accepted by reviewers and mentors because it is more work, leading to growing parallel infrastructure and second-class code. Neither of these outcomes is desirable in my opinion. > It won't hamper the normal process since ready patches still get > compiled and submitted through the mailing list (ML). In fact it may > help scale the review process by getting peer reviewers involved. The > idea is that we have an incubator environment before the ML which > allows for playful learning and tracking of patches that may (or may > not) make it into main line. I think it is very important to have a > low barrier to entry when it comes to submitting package recipes. I appreciate your desire to reduce the work load of reviewers/mentors on the mailing list. I have some doubts about whether this approach would be feasible, though. There already *are* external repositories outside of Guix, either implemented to be used with GUIX_PACKAGE_PATH (such as your own “genenetwork/guix-bioinformatics” repo or the MDC’s “guix-bimsb”) or as forks of Guix (e.g. public versions of what most Guix developers do locally to add packages). I have not seen any concerted efforts to upstream package definitions from either of these classes of repositories. This makes me wonder if the presumed benefits of an incubator could actually be realised. I would like to advise against recommending an “incubator” procedure like this as an official alternative to submissions to the mailing list. Our workflow involving the mailing list is far from perfect. We had further discussions over post-FOSDEM dinner and drinks and there seemed to be consensus among the people present (including long time contributors, reviewers, and successful mentors) that it would be a great improvement to keep track of package contributions in a separate Debbugs instance (e.g. one “bug” per package submission). It gives us a way to track the state of things more easily, it accomodates people who prefer to use a web browser, it permits us to continue to use email, and it doesn’t force yet another account onto submitters. Admittedly, the web interface that Debbugs comes with is kinda bland and hard to use, so a second step would be to develop a better UI frontend to Debbugs that would be closer to what people expect from an issue tracker. This was discussed before at and we could request a separate Debbugs instance for “guix-packages@gnu.org” *right now* if we wanted to. What do other people think about this? -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net