From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Subject: bug#22629: Channels not needed for a stable branch Date: Wed, 29 Aug 2018 23:02:04 +0200 Message-ID: <87mut47upf.fsf@gnu.org> 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]:33522) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fv7cF-0000wy-IT for bug-guix@gnu.org; Wed, 29 Aug 2018 17:03:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fv7cE-0004a9-RU for bug-guix@gnu.org; Wed, 29 Aug 2018 17:03:03 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:60731) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fv7cE-0004a1-NG for bug-guix@gnu.org; Wed, 29 Aug 2018 17:03:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fv7cE-00057k-EZ for bug-guix@gnu.org; Wed, 29 Aug 2018 17:03:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87lg8pccys.fsf_-_@netris.org> (Mark H. Weaver's message of "Wed, 29 Aug 2018 13:14:03 -0400") 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 Hello Guix, Mark H Weaver skribis: > Both of you seem to have reached the conclusion that third-party > channels are a prerequisite for having a 'stable' branch. I disagree. Same here. We could already be doing that (I=E2=80=99m skeptical about the feasibility, maintainability, and relevance of a =E2=80=9Cstable=E2=80=9D b= ranch in the sense of Debian stable, but that=E2=80=99s another story.) > I agree with both of you that a 'stable' branch of Guix would be > tremendously useful. I've often wanted it myself, and I still do. > > 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. I had this example in mind too: the kernel technically supports out-of-tree modules, but kernel developers have always resisted pressure to freeze APIs. Because this policy has been stated upfront very clearly and has remained unchanged, out-of-tree module developers know that that the compatibility burden is on them. There=E2=80=99s flexibility, along with a strong incentive to get things in the mainline kernel. This is the outcome I=E2=80=99d like to achieve: give users some welcome flexibility, but make it clear that it=E2=80=99s best-effort. Ludo=E2=80=99.