From mboxrd@z Thu Jan 1 00:00:00 1970 From: Petter Subject: Re: We need an RFC procedure [Re: Services can now have a default value] Date: Thu, 27 Apr 2017 18:37:49 +0200 Message-ID: <20170427183749.2c8b817e@mykolab.ch> References: <87shl9qo7h.fsf@gnu.org> <877f2go3wn.fsf@zancanaro.id.au> <877f2gksbs.fsf@gnu.org> <8737d32abz.fsf@zancanaro.id.au> <87bmrr4ghh.fsf@gnu.org> <874lxjnzyx.fsf@zancanaro.id.au> <87bmrp8lk6.fsf@gnu.org> <8737d1nxbd.fsf@zancanaro.id.au> <20170422004634.4oedqmsebpctjqk4@abyayala> <878tmsud8m.fsf@elephly.net> <20170422100811.mr3t5rgh6n44xvdk@abyayala> <87pog4gihe.fsf@gnu.org> <87wpabsa71.fsf@elephly.net> <87bmri7zce.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]:54470) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d3mQf-00062B-9S for guix-devel@gnu.org; Thu, 27 Apr 2017 12:38:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d3mQb-0004tC-3t for guix-devel@gnu.org; Thu, 27 Apr 2017 12:38:05 -0400 In-Reply-To: <87bmri7zce.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 =?UTF-8?B?Q291cnTDqHM=?= Cc: guix-devel , Carlo Zancanaro If I may make a suggestion, coming from a place of ignorance. How about a stable branch that would be opt-in? On Thu, 27 Apr 2017 15:29:53 +0200 ludo@gnu.org (Ludovic Court=C3=A8s) wrote: > Ricardo Wurmus skribis: >=20 > > It=E2=80=99s a little unfortunate that packages are developed together = with > > everything else, because this means that there is no way for people to > > opt out of breaking changes until the next release without also opting > > out of getting any updates at all. =20 >=20 > It=E2=80=99s both a strength and a weakness I guess. The good thing is t= hat we > can make changes that affect everything at once. The bad thing is what > you mention. >=20 > We could use feature branches more, with the downside that they would > probably get little additional testing, precisely because one would have > to choose between features and packages. >=20 > Thoughts? >=20 > Ludo=E2=80=99. >=20