From mboxrd@z Thu Jan 1 00:00:00 1970 From: ng0 Subject: Re: Guix package incubator (later a channel) Date: Tue, 7 Feb 2017 20:59:46 +0000 Message-ID: <20170207205946.7z7oezbrahwnfgpd@wasp> References: <20170206190923.GA3592@mail.thebird.nl> <87shnplrjh.fsf@elephly.net> 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]:35958) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cbCq9-0004yr-Tp for guix-devel@gnu.org; Tue, 07 Feb 2017 15:58:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cbCq5-0003FS-Md for guix-devel@gnu.org; Tue, 07 Feb 2017 15:58:18 -0500 Received: from latitanza.investici.org ([2001:888:2000:56::19]:43422) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cbCq5-0003EL-9R for guix-devel@gnu.org; Tue, 07 Feb 2017 15:58:13 -0500 Content-Disposition: inline In-Reply-To: <87shnplrjh.fsf@elephly.net> 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 On 17-02-07 20:38:58, Ricardo Wurmus wrote: >=20 > Hi Pjotr, >=20 > 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. >=20 > > 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. Th= e > > 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. >=20 > 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. >=20 > 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. >=20 > I see two possible outcomes of establishing an additional =E2=80=9Cincu= bator=E2=80=9D > 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. >=20 > > 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. >=20 > I appreciate your desire to reduce the work load of reviewers/mentors o= n > 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 =E2=80=9Cgenenetwork/guix-bioinformatics=E2=80=9D repo or the = MDC=E2=80=99s > =E2=80=9Cguix-bimsb=E2=80=9D) 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. >=20 > This makes me wonder if the presumed benefits of an incubator could > actually be realised. I would like to advise against recommending an > =E2=80=9Cincubator=E2=80=9D procedure like this as an official alternat= ive to > submissions to the mailing list. >=20 > 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 =E2=80=9Cbug=E2=80=9D 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, an= d > it doesn=E2=80=99t force yet another account onto submitters. >=20 > Admittedly, the web interface that Debbugs comes with is kinda bland an= d > 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. >=20 > This was discussed before at > > and we could request a separate Debbugs instance for > =E2=80=9Cguix-packages@gnu.org=E2=80=9D *right now* if we wanted to. >=20 > What do other people think about this? >=20 > -- > Ricardo >=20 > GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC > https://elephly.net >=20 >=20 The here mentioned debbugs solution would work now and it would have an immediate=20 effect. I really welcome this solution as a first step to try out alternatives and I would make use of it. Regarding the approach Pjotr suggested: would it be like https://wiki.gentoo.org/wiki/Gentoo_Github ( See also: https://wiki.gentoo.org/wiki/Gentoo_Github#See_also ) ? I do share the voiced concerns - there are little reviewers, and while th= e situation with reviews is bad it is really a people problem. Tools can improve access for newcomers, but they won't fix the reviewers > patches ratio. Here are further ideas to motivate newcomers: We regulary get questions on HOW to start and WHAT to use (for contributing) etc. Okay, improving upstream documentation would be ideal, but until then we can have a better "get started contributing to Guix" section, and maybe a link on the website to this (we already kind of have), Encourage to read the open bugs (point to a "low hanging fruits" list of bugs and things to do around Guix), and even more get people to review through encouragment and ...stuff... (kind words, etc etc). Goodnight! --=20 ng0 -- https://www.inventati.org/patternsinthechaos/