From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Enge Subject: Re: A registry for distributed sources and binaries Date: Sun, 24 Jul 2016 15:58:28 +0200 Message-ID: <20160724135828.GA6502@solar> References: <579027b7.VHXjhpPxQC3AAmeY%pjotr.public12@email> <8760rznoh1.fsf@gnu.org> <20160722004130.GA10340@thebird.nl> <874m7hk6dz.fsf_-_@gnu.org> <20160724033027.GA20236@thebird.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:52734) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bRJvS-0003fj-To for guix-devel@gnu.org; Sun, 24 Jul 2016 09:58:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bRJvO-0003oz-Ke for guix-devel@gnu.org; Sun, 24 Jul 2016 09:58:37 -0400 Received: from mailrelay7.public.one.com ([91.198.169.215]:61852) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bRJvO-0003on-6m for guix-devel@gnu.org; Sun, 24 Jul 2016 09:58:34 -0400 Content-Disposition: inline In-Reply-To: <20160724033027.GA20236@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 Hello, On Sun, Jul 24, 2016 at 05:30:27AM +0200, Pjotr Prins wrote: > 2. Slightly complicated (you need a Guix source tree etc.) as far as I understand it, our "data is code" approach makes it necessary to have the Guix tree around in any case. "guix package -i ruby" looks up the package variable with name "ruby" in the local Guix tree, which may be installed in ways different from using git ("guix pull" comes to mind). On Sun, Jul 24, 2016 at 09:41:49AM +0200, Pjotr Prins wrote: > In my mind we don't need much of an API. We need a way for plugins to > tell what hooks they provide and then call into these hooks. That is > all. Plugins don't get access to Guix internals per se - though we > could run them in the same space. So when your registry defines a package that depends on ruby, it somehow needs to import the scheme variable of the same name, which resides in, say, the central Guix tree. So it is not a matter of simply adding hooks. (Of course, I suppose that external scheme files could be "added" to the local tree as the files in GUIX_PACKAGE_PATH are, but I am not sure whether this is what you mean). > After some thought I am coming to the following: my primary goals are > to lower the barrier to entry > 1. People are not aware about the work of others > 3. No binary distribution One of my main concerns with your suggestion (besides the technical one) is that I do not think it lowers the barrier to entry, but it diverts the efforts. With package repositories full of packages around, where a half- baked recipe can simply be dropped for the world to use, what would be the incentive of contributing back into the main project? My impression is that it is extraordinarily easy to contribute to Guix: Anybody can post packages to the mailing list, and after a bit of back and forth, they are usually added. No copyright assignment, no need to become a "Guix maintainer". Making it even easier essentially means dropping quality control. Then packages of bad quality floating around Guix would mean bad publicity. A problem, as mentioned in another reply, is the lack of people doing code review, which is not a very rewarding task. That can be changed by everyone of us :-) And I think we need to work on our tooling and processes; the approach of submitting patches to this mailing list is not set in stone. Apart from that, I do not think that the claim of patch loss is justified: This may happen from time to time, but not on a regular basis. On Sun, Jul 24, 2016 at 05:30:27AM +0200, Pjotr Prins wrote: > have people collaborate on each others packages without some > centralized 'opinion'. On Sun, Jul 24, 2016 at 03:48:48PM +1000, Jookia wrote: > We're all a bit frustrated > with each other at the moment because we have different goals. > There could be a guix-jookia, guix-nonfree for those > that really want to run it on their nonfree systems. Is this the elephant in the room? Besides quality control, which is necessary to make a distribution with thousands of packages maintainable by just a few people, our only "restrictive" opinion is supporting only free software - anything that is free software can go in. But this is central to the project and a point where no compromises can be made. Our goal is to support free software and only free software, which is a promise to our users, supporters and ourselves. Andreas