From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arun Isaac Subject: Re: Adopt a patch! Date: Tue, 19 Sep 2017 19:52:32 +0530 Message-ID: References: <877ex5d555.fsf@gnu.org> <4fecd5dd.AEQAQDR72NkAAAAAAAAAAAOzWv8AAAACwQwAAAAAAAW9WABZudnG@mailjet.com> <87d16pf5x5.fsf@gnu.org> 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]:50638) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1duJQm-0002ZS-41 for guix-devel@gnu.org; Tue, 19 Sep 2017 10:23:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1duJQg-00021R-BL for guix-devel@gnu.org; Tue, 19 Sep 2017 10:23:20 -0400 Received: from o132.p8.mailjet.com ([87.253.233.132]:47299) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1duJQg-00020F-0m for guix-devel@gnu.org; Tue, 19 Sep 2017 10:23:14 -0400 In-reply-to: <87d16pf5x5.fsf@gnu.org> 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: Ludovic =?iso-8859-1?q?Court=E8s?= Cc: guix-devel > At the time, Andy (I think) suggested that collaborative maintainership > the way we do it might actually =E2=80=9Cwork better=E2=80=9D and scale= better. In the > meantime, there have been long discussions in Debian about whether > package maintainers should be dropped. Some rightfully argued that > maintainership gives a sense of =E2=80=9Cownership=E2=80=9D to the main= tainer(s), which, > whether we want it or not, discourages others from contributing to the > package. Yes, makes sense. Sometimes, "ownership" also makes maintainers somewhat less polite. > I=E2=80=99m really summarizing here (there were a couple of articles on= LWN), Links to these articles would be nice. Do you have them? > but to me that=E2=80=99s a very good argument. I=E2=80=99d rather have= a sense of > shared responsibility that this. > > As for chaos, I don=E2=80=99t think it=E2=80=99s that bad. :-) As ng0= wrote, there are > de facto people who are more familiar with specific packages. They > don=E2=80=99t have an official title, but they are the ones who=E2=80=99= d review changes > to these packages and provide advice. It seems to work well so far. Just thinking out loud: Maybe, we need more people with commit access. Theoretically, anyone can review a patch, but ultimately it is people with commit access who will have to finally apply and push the patch. As the rate of submission of patches grows, this increases the work load on those with commit access. More automation with regard to reviewing patches might help. For example, would it be possible to automatically or semi-automatically detect the license of a package? Many packages have multiple licenses, and it is quite tedious to grep through the source code and identify all the licenses involved. Even partial automation could be useful here. Github does some kind of license detection. I have no idea what kind of algorithm they use, though. Also, I keep forgetting to return #t at the end of phases. Could there be some way to auto-detect this? > What is more scary is massive imports from external repos (CPAN, etc.). > I think we cannot handle all of it, not with our =E2=80=9Cquality=E2=80= =9D guidelines > and not with the pace at which these repos change. True. It is very difficult to keep up with those gigantic repos. > At the GHM, we were discussing that, probably, we=E2=80=99ll have to ac= cept for > Guix to be a gateway to those repos (at least for the =E2=80=9Cnon-core= =E2=80=9D subsets > of the repos). Concretely, one could do =E2=80=9Cguix package -i cpan!= Foo::Bar=E2=80=9D > and have the package DAG imported and built live. It=E2=80=99s either = that or > people will use CPAN=E2=80=99s own tools to achieve this. It would be nice to have some kind of "upstream packaging" (like AppImage), so that developers can package their software themselves. It would be a quick way for new projects to get people to try out their work. I believe there has been discussion and work on these lines in Guix. I'm not very familiar with it. I'll read up.