From mboxrd@z Thu Jan  1 00:00:00 1970
From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=)
Subject: Re: Ungrafting
Date: Mon, 02 May 2016 17:54:37 +0200
Message-ID: <87shy0foaq.fsf@gnu.org>
References: <20160501202057.GB7127@jasmine> <87shy0vb11.fsf@netris.org>
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]:58910)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <ludo@gnu.org>) id 1axGBW-0003F4-BN
	for guix-devel@gnu.org; Mon, 02 May 2016 11:55:04 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <ludo@gnu.org>) id 1axGBK-0006Ve-JL
	for guix-devel@gnu.org; Mon, 02 May 2016 11:54:52 -0400
In-Reply-To: <87shy0vb11.fsf@netris.org> (Mark H. Weaver's message of "Mon, 02
	May 2016 09:34:34 -0400")
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: Mark H Weaver <mhw@netris.org>
Cc: guix-devel@gnu.org

Mark H Weaver <mhw@netris.org> skribis:

> Leo Famulari <leo@famulari.name> writes:
>
>> When committing a bug fix with a graft, I think it would be a good idea
>> to follow up on some other branch with a commit that makes the same
>> change without a graft.
>>
>> Core-updates was suggested on IRC. This would mean that after each graft
>> commit, master would need to be merged into core-updates, and then the
>> "ungrafting" patch could be applied.
>
> Merging those two will be awkward.  In my experience, the result of git
> automatically merging these two commits is to update the main package
> *and* to graft it.

Good point.

> For this reason, I think it's preferable for the ungrafted commit to
> be on top of the grafted one, i.e. it should remove the graft and
> update the origin package in a single commit.
>
> In practice, this means that after applying the graft to master, master
> should be merged into core-updates before applying the ungrafting commit
> to core-updates.
>
> What do you think?

Sounds like a good workflow, yes.

Regarding builds, it=E2=80=99s really a scheduling problem.  We have period=
ic
update branches (gnome-updates, python-updates, core-updates), and
Something could tell you whether a change is eligible for one of these
branches, so we could batch related changes together.

Ludo=E2=80=99.