From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 29 14:26:58 2018 Received: (at 22629) by debbugs.gnu.org; 29 Aug 2018 18:26:58 +0000 Received: from localhost ([127.0.0.1]:37415 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fv5BB-0005nA-P7 for submit@debbugs.gnu.org; Wed, 29 Aug 2018 14:26:57 -0400 Received: from sender-of-o51.zoho.com ([135.84.80.216]:21136) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fv5B9-0005n0-LE for 22629@debbugs.gnu.org; Wed, 29 Aug 2018 14:26:56 -0400 ARC-Seal: i=1; a=rsa-sha256; t=1535567197; cv=none; d=zoho.com; s=zohoarc; b=RO7nMPpnQl53J8bbid7VtJqItHIbr3IFpZoFPAV71bwFfFhG6xLfDZiIqyJKzTeC0Y60Sj9IVG3+Qn6g2ZWoS9ru2iGAUAccq76/3MZ8UzldCpNZzyhf5XPwsMT+Gi5+FnGk2QNHGoBYgBcoR8LdIh3VmktS+4/dn3MjZDpo1os= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1535567197; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results; bh=zCA4tlX9kDHiK9mqZsNwMLblfeZARQWkcyxQ8ALfLGM=; b=XKynQI2qBW9tGGD9X4SP0MIFGg519P9p1iThAmn7BexLhm392zAiXqC8ZQZEaV2jf+xZbCOC7M72/xVNhlCSjmKSLiaM3+M2lpFjyp57qhMZJMGIuZDC5q/TqqFdSMXw4Hb+NkeuV2lQtItyjAIYLnr0EcnC1d+NKSTgZpVqIVo= ARC-Authentication-Results: i=1; mx.zoho.com; dkim=pass header.i=elephly.net; spf=pass smtp.mailfrom=rekado@elephly.net; dmarc=pass header.from= header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1535567197; s=zoho; d=elephly.net; i=rekado@elephly.net; h=References:From:To:Cc:Subject:In-reply-to:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; l=2323; bh=zCA4tlX9kDHiK9mqZsNwMLblfeZARQWkcyxQ8ALfLGM=; b=SFmDKMHNubZ2tBx3ZKlWkLkKZ79ovE4DY+3OrIYq2mQIlxZN0wU0POTw7Rl5Gb6f jp6lUyoSNd6t2RXyMS5aiNqmNJjlPssYEpyw6enzZ2YFq674QkRgim+e2C2Nl2j2eMC A92YWQMoowfxHYIM0phUBZKWB0Qh3j5fyd/rURpk= Received: from localhost (port-92-200-60-110.dynamic.qsc.de [92.200.60.110]) by mx.zohomail.com with SMTPS id 1535567196295901.3746066647864; Wed, 29 Aug 2018 11:26:36 -0700 (PDT) References: <87vb5vsffd.fsf@gnu.org> <87pny2iks2.fsf@gnu.org> <877ekagtg9.fsf@netris.org> <87zhx5msfl.fsf@pompo.co> <87lg8pccys.fsf_-_@netris.org> User-agent: mu4e 1.0; emacs 26.1 From: Ricardo Wurmus To: Mark H Weaver Subject: Re: bug#22629: Channels not needed for a stable branch (was: Channels!) In-reply-to: <87lg8pccys.fsf_-_@netris.org> X-URL: https://elephly.net X-PGP-Key: https://elephly.net/rekado.pubkey X-PGP-Fingerprint: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC Date: Wed, 29 Aug 2018 20:26:32 +0200 Message-ID: <87zhx59gh3.fsf@elephly.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-ZohoMailClient: External X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 22629 Cc: Konrad Hinsen , Alex Sassmannshausen , 22629@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi Mark, > I'd like to say again that I have grave concerns that this could be the > death-knell for long-term innovation in Guix. It's likely that whenever > a change is proposed that will break these third-party channels, there > will be resistance, and efforts to preserve backward compatibility. GUIX_PACKAGE_PATH already had that same problem (and did not provide a solution for it). With channels we can at least add more information about a collection of modules, e.g. what version of Guix it is known to work with. So channels really flesh out the feature provided by GUIX_PACKAGE_PATH, elevating it from a simple environment variable to one that can take additional context into account. I think that=E2=80=99s a worthwhile step to take. I agree with your sentiment that a mechanism based on a simple environment variable does not instill confidence, whereas a special mechanism like channels could signal to users that it=E2=80=99s a feature t= hat provides some guarantees. But I disagree with your assertion that this would be =E2=80=9Ca death-knell to innovation=E2=80=9D. That seems like an= exaggeration to me. > My point is that I want to keep our APIs internal and unfrozen for the > same reason that Linux, the kernel project, does. Linux refuses to > support out-of-tree drivers and modules, and thereby retains its freedom > to change their internal APIs. Often they change how things work > internally and this entails doing massive find-replace on every driver > in the tree. This has been a crucially important factor in their > long-term success. [=E2=80=A6] > We should persue a similar model. The crucial thing is to always keep > the package modules together with the rest of Guix. I agree. That is and remains our recommendation. I still want most packages to end up in Guix proper. There are collections of packages for which this does not make sense, though, and I think that it is better to have a more formal mechanism that can also be used to describe the limits of compatibility than just a simple environment variable. I also agree with you that we don=E2=80=99t need channels for providing a s= table branch. The biggest obstacle to providing a stable branch is not technical, but it requires people maintaining it. -- Ricardo