From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: bug#22629: Channels not needed for a stable branch (was: Channels!) Date: Wed, 29 Aug 2018 20:26:32 +0200 Message-ID: <87zhx59gh3.fsf@elephly.net> References: <87vb5vsffd.fsf@gnu.org> <87pny2iks2.fsf@gnu.org> <877ekagtg9.fsf@netris.org> <87zhx5msfl.fsf@pompo.co> <87lg8pccys.fsf_-_@netris.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]:49522) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fv5FX-0004xI-28 for bug-guix@gnu.org; Wed, 29 Aug 2018 14:31:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fv5BF-0007Wz-Tf for bug-guix@gnu.org; Wed, 29 Aug 2018 14:27:05 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:60630) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fv5BF-0007Wn-N6 for bug-guix@gnu.org; Wed, 29 Aug 2018 14:27:01 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fv5BF-0005nT-IY for bug-guix@gnu.org; Wed, 29 Aug 2018 14:27:01 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-reply-to: <87lg8pccys.fsf_-_@netris.org> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Mark H Weaver Cc: 22629@debbugs.gnu.org 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