From mboxrd@z Thu Jan  1 00:00:00 1970
From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=)
Subject: Branching and rebuild scheduling strategy
Date: Tue, 18 Oct 2016 14:41:00 +0200
Message-ID: <87wph5ltib.fsf_-_@gnu.org>
References: <1476104563-29373-1-git-send-email-h.goebel@crazy-compilers.com>
	<878tts9ffy.fsf@gnu.org> <58008FB7.7080101@crazy-compilers.com>
	<87shruka1j.fsf@gnu.org> <5805D345.7040509@crazy-compilers.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Return-path: <guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org>
Received: from eggs.gnu.org ([2001:4830:134:3::10]:43528)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <ludo@gnu.org>) id 1bwThc-0006To-05
	for guix-devel@gnu.org; Tue, 18 Oct 2016 08:41:08 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <ludo@gnu.org>) id 1bwThW-0000QM-UP
	for guix-devel@gnu.org; Tue, 18 Oct 2016 08:41:08 -0400
In-Reply-To: <5805D345.7040509@crazy-compilers.com> (Hartmut Goebel's message
	of "Tue, 18 Oct 2016 09:46:13 +0200")
List-Id: "Development of GNU Guix and the GNU System distribution."
	<guix-devel.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/guix-devel>,
	<mailto:guix-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/guix-devel/>
List-Post: <mailto:guix-devel@gnu.org>
List-Help: <mailto:guix-devel-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/guix-devel>,
	<mailto:guix-devel-request@gnu.org?subject=subscribe>
Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org
Sender: "Guix-devel" <guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org>
To: Hartmut Goebel <h.goebel@crazy-compilers.com>
Cc: guix-devel@gnu.org

Hartmut Goebel <h.goebel@crazy-compilers.com> skribis:

> Am 17.10.2016 um 22:14 schrieb Ludovic Court=C3=A8s:
>> Once =E2=80=98core-updates=E2=80=99 is merged (hopefully in a few days),=
 we could start
>> a =E2=80=98staging=E2=80=99 branch and put changes that require between =
~300 and ~1200
>> rebuilds.  The idea would be to close the branch much more quickly than
>> core-updates (the changes should be less disruptive, with little chance
>> of breaking things.)
>
> This is a good idea, too.
>
> I meant some branch like "core-updates-next", as a staging branch for
> the next "core-updates" cycle, too. So if he core-updates are currently
> build, we most likely do not want to tough it. But we could already push
> some changes to core-updates next to get them off our todo-lists.
>
> But maybe this is just what you call "staging" branch :-)

Yes.  To summarize:

| name           | rebuilds       | merge frequency | type                 =
         |
|----------------+----------------+-----------------+----------------------=
---------|
| core-updates   | > 1200         | 2.5 months      | possibly disruptive  =
         |
| staging        | 300 < n < 1200 | 3 weeks         | non-disruptive       =
         |
| master         | < 300          | n/a             | non-disruptive       =
         |
| $TOPIC-updates | > 300          | when it's ready | topic-specific (e.g.,=
 Python) |

Of course this depends on the power of our build farm and on how
disciplined we are.  ;-)  That is, we should pay attention to the status
of these branches on Hydra, fix issues in a timely fashion, and merge
them as soon as they're almost entirely built.

What do people think?

Ludo'.