From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id GGgdDR+hkGSBHQEASxT56A (envelope-from ) for ; Mon, 19 Jun 2023 20:40:31 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id sEMYDR+hkGRwXgEA9RJhRA (envelope-from ) for ; Mon, 19 Jun 2023 20:40:31 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 088602D42D for ; Mon, 19 Jun 2023 20:40:31 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qBJnL-0000lk-61; Mon, 19 Jun 2023 14:40:07 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qBJnJ-0000lK-Ty for guix-devel@gnu.org; Mon, 19 Jun 2023 14:40:05 -0400 Received: from mail-40134.protonmail.ch ([185.70.40.134]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qBJnH-00070z-Ay for guix-devel@gnu.org; Mon, 19 Jun 2023 14:40:05 -0400 Date: Mon, 19 Jun 2023 18:39:49 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1687200000; x=1687459200; bh=WTfZ1vurKavlliIkex+npO7occqyuXQFGOXjoxYgijg=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=lpELGKhpk2+2cqvyzUAxazHZcBqQQI/bB6Tw+nDTZzfKtKSGZlZvm96tRyodEuVL7 rl+Zu/SCmQnJoYQnw8UhiB07pX+T/puDUzAqNajvsEPYLZbXl0Ag0GbQB+WFINIbHA bDdQ+aXADVPkgbpFNJ8SAh37hXrRn/3126Znoan7EuD4UY2+iNuQgxZQl89ho43vV/ sU+1IauMZc6fGskzvSgqW9d0xWmtHPRyWzdlTb9jiu+ZvIC+3Y0dqTPxs3hzu2Dy59 MfcyU60uO4XUymLkhZPQa73PNdbnNOzl/1J0vkAPMie/S7zWmc8q70eZlvfTBmfF8N UhvcAJL3TShXg== To: Christopher Baines From: John Kehayias Cc: guix-devel@gnu.org Subject: Re: Changes to the branching/commit policy Message-ID: <87wmzzqosu.fsf@protonmail.com> In-Reply-To: <87edmal7jk.fsf@cbaines.net> References: <87y1kuyqew.fsf@cbaines.net> <87o7lktodm.fsf@cbaines.net> <871qiaslx6.fsf@protonmail.com> <87edmal7jk.fsf@cbaines.net> Feedback-ID: 7805494:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.70.40.134; envelope-from=john.kehayias@protonmail.com; helo=mail-40134.protonmail.ch X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list 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+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN ARC-Seal: i=1; s=key1; d=yhetil.org; t=1687200031; a=rsa-sha256; cv=none; b=MRnHYF/+BhIdwXfXnO+NfOXLN0adjgaRaUAAsuhYe2ieL6x4irscOC3+jjzi2TpHc6sUDv X7TQWwdfYcMb+Lnrv53sMVZxa8rixdwPFKd4oTIORFUjA7gXcA3CzXoZ5lmoSix/waZSEF pAm2VEWAibex48+Qce0XZINHv+1eM6vRfN1gN55n2H+qmry2grorZ+AT65dXSdK+XeHBNG ywXeT3Q2ubCC1cM9nkbHFsZQFMIouRyV/CwSKIEaodOKyBjUV182qwUY0p5O2K7b45xaVK cJUCqKEItiCulcUr7jG80PkYxUxJ2SNOMQHt+7elR61MgdZBrPmzVcskAuLUIA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=protonmail.com header.s=protonmail3 header.b=lpELGKhp; dmarc=pass (policy=quarantine) header.from=protonmail.com; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1687200031; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=WTfZ1vurKavlliIkex+npO7occqyuXQFGOXjoxYgijg=; b=Elee3aipcYxvqWwP541NHyiYZorJvTafSQOBL9g9ZdJqZQpnku4vZJ92TVaCYgAcf9halr i+8Dj+JTkYtcj3u0XSNzWfZ8yVg0QlIWs/vF2N9Hql6OynpEbNCsgG0Ar67rqkWP4UKM5H Zmu5xfXKVl7TpjwDsOOn6wYPIAvNk7HcPfzVEPPNKx3ivhK9K6nuhr2t5j5y6JPK6ajxsD mWCo4srubiRQdLvEs1O9wjZEl7xkzFPsjjR24ObEyRhV+F74AzkZCQImkgvGbHzz4WvPtb dtusXPqj4UPEUo6IpJ3dGMmeA1zTmYEDEPic+cNB3PODqOsPj4LPHv9/TqyYxw== Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=protonmail.com header.s=protonmail3 header.b=lpELGKhp; dmarc=pass (policy=quarantine) header.from=protonmail.com; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Scanner: scn0.migadu.com X-Migadu-Spam-Score: -4.93 X-Spam-Score: -4.93 X-Migadu-Queue-Id: 088602D42D X-TUID: +xthH7CT1T+e Hi Chris, On Sat, Jun 17, 2023 at 10:57 AM, Christopher Baines wrote: > > John Kehayias writes: > >> Thanks for these changes! Question on branches (sorry if this was >> covered in a previous thread, but now that we have new language in the >> manual I figure this is a good place): do we have a convention on >> branch names and subject headers for emailing patches for the branch? >> e.g. does [PATCH 1/3] do anything on the QA end? > > On the names of branches, there's some typical names like XXXX-team, or > wip-XXXX but really it's up to you. > > QA doesn't currently support applying patches to anything other than the > master branch, but that's something that should probably be addressed at > some point. I'd encourage you to do whatever you think is useful here, > then hopefully QA can use that to act appropriately. > Sounds good, a simple identifier in the "[PATCH]" subject, like for core-updates, seems simple enough to get started. >> Or does the section about branch building for once patches are pushed >> to a branch on Savannah? > > I'm not sure what you're asking here. I'm confused myself over my wording, but I remember what I was trying to get at: Currently QA doesn't build patches if they cause a large number of rebuilds correct? So for building a branch that requires this, will that only happen on Cuirass with a new jobspec for the branch? Or will this be addressed through changes to how QA builds? (Maybe this answered below actually.) > >> Does that mean pushing to a branch should follow the same 1-2 week >> review allowing QA builds? I guess patch series are always built >> together on QA but wondering if there is anything else to be aware of >> or needs mentioning to keep things tidy and clear. > > Those durations mentioned in the commit policy [1] are intended to allow > for human review. For QA, it doesn't need to be time based as it can > report it's progress. Obviously it does need a bit of time to check > things, but I prefer to leave it up to people to assess the changes and > any information provided by QA and decide when it's appropriate to push. > > 1: > A separate issue which I wanted to get at was about pushing changes to any branch on Savannah. Do we expect those to be at the same state as anything that would go directly to master, just pending the testing of builds basically? So, after the usual review period? Or can those be more WIP and not polished yet? I suppose this is for a team/people working on a branch to discuss and how it will then be merged to master. > On keeping things clear, I think with branches I'm hoping the issue > tracker can help with this, which is why there's now a strong > requirement to create a guix-patches issue when you want to merge a > branch, and use those issues to manage the timing. > > For those issues, there's currently a convention of using the following > title: `Request for merging "XXXX" branch` e.g. [2]. That helps QA find > these issues and act accordingly, but of course if someone comes up with > a better way of naming these issues, we can just adjust the code in the > qa-frontpage. > I see, that's a nice way to then group up discussion if a branch has a bunch of separate patch threads. Looks like a good idea! So, to be concrete, with the mesa patch I just sent, I can open a merge request issue for QA to process the branch, once the branch is actually created on Savannah? I assume with the pretty trivial version change here I could do that to see how the builds go, but I'll hold off pending the thread I just started about this branch/team. > 2: > 3: > > > Thanks for your questions :) > > Chris > And thanks again for all you do here, the Guix tooling has been making great progress! John