From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: core-updates merged! Date: Wed, 26 Mar 2014 16:46:25 +0100 Message-ID: <87txal0xpq.fsf@gnu.org> References: <87mwgn8twp.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]:46547) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WSq2H-0001kV-Pn for guix-devel@gnu.org; Wed, 26 Mar 2014 11:46:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WSq28-0002wo-Cw for guix-devel@gnu.org; Wed, 26 Mar 2014 11:46:37 -0400 Received: from hera.aquilenet.fr ([2a01:474::1]:48604) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WSq28-0002wh-5r for guix-devel@gnu.org; Wed, 26 Mar 2014 11:46:28 -0400 Received: from localhost (localhost [127.0.0.1]) by hera.aquilenet.fr (Postfix) with ESMTP id 95D73209A for ; Wed, 26 Mar 2014 16:46:26 +0100 (CET) Received: from hera.aquilenet.fr ([127.0.0.1]) by localhost (hera.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPPIB5B0cQxw for ; Wed, 26 Mar 2014 16:46:26 +0100 (CET) Received: from pluto (reverse-83.fdn.fr [80.67.176.83]) by hera.aquilenet.fr (Postfix) with ESMTPSA id 4FF191C52 for ; Wed, 26 Mar 2014 16:46:26 +0100 (CET) In-Reply-To: <87mwgn8twp.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Tue, 18 Mar 2014 15:26:30 +0100") 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-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: guix-devel@gnu.org I=E2=80=99ve just merged core-updates in master, and Hydra has already built most of it. So that brings glibc 2.19, grep 2.18, libgc 7.4, guile 2.0.11, bash 6.3, the ability to use directories as package sources (instead of tarballs), and a bunch of other updates and improvements. It=E2=80=99s been more than 3 months between this merge and the previous on= e, which is probably too much. To avoid lingering branches, I think we should have a more formal, time-based process. For instance, we would let the branch live for N months exactly, and freeze it at N months minus one week. GCC and glibc are released roughly every 6 months, but typically with a 3 month offset. So I would go for N =3D 2 or N =3D 3. Maybe N =3D 2 is better as it would allow us to make core improvements and small upgrades more often. Thoughts? Thanks, Ludo=E2=80=99.