From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-94264-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by finch.gentoo.org (Postfix) with ESMTPS id 9F6C11382C5
for <garchives@archives.gentoo.org>; Thu, 22 Apr 2021 13:01:35 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 30544E08EB;
Thu, 22 Apr 2021 13:01:32 +0000 (UTC)
Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
by pigeon.gentoo.org (Postfix) with ESMTPS id F1C11E08BB
for <gentoo-dev@lists.gentoo.org>; Thu, 22 Apr 2021 13:01:31 +0000 (UTC)
Received: by mail-io1-xd30.google.com with SMTP id g125so16751717iof.3
for <gentoo-dev@lists.gentoo.org>; Thu, 22 Apr 2021 06:01:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:content-transfer-encoding;
bh=CQ4HFqm4/DI1/L/23m17UW0Ffs3LGFWpTjBbpRjg+Ak=;
b=HhOKBdtPLnB5l3oV2mwYPSOmtNfjo4oPE0KNSsIRQASo/5oGuE5eYMOXYUPahOdC/J
lac0oZJ6fNACbbciDr0H8ZSxMfnFyqjYp1UChXHSB96vn27MiG4pAeE0t5pL0O6BwL9J
uSGWjJiXGLNNBRZ6lMoRDthB4erSFTEianfHat6g6YJyE9BbEpgOiVnQX2gMOuqOJESy
VkW7zq2PDGQpjFVPEaEUAvdEgGE4MkEXtzXPjjqr+8xfhU+ZinnOKe9mPBWRjty5RzkD
xOJRIOl6H2kmmhQKCWfjoCylcI11Vy3Le0wwZ18eNQSCD36bZfIyaCo1l5j8QFIhnI7J
TGrw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:content-transfer-encoding;
bh=CQ4HFqm4/DI1/L/23m17UW0Ffs3LGFWpTjBbpRjg+Ak=;
b=lYvTdPJoWySYrx1BiL9792zxZu399xl5qpmJIrcvyRSpQdBkczvFW8+0N2zNwfYYNH
GwBpsPIrRRZGs0tlu+bMGmfW4hK7uue6Jr9cSN/MUBK+4KD+VG04/vGpCSApvL2Nunm5
r4P7E3fSt3pIq6+lnRNHhesn20OpLnoA+FCgoEQacnKpQscWL2fQQ0X0pM9uV+UNWzzO
s4ZqBY+KDqh+k/wyF1Hw+rlqREFcrwEWVQ8AQgNqkxPVU0JQf/7j1lMc71jIakqNZM8f
L5/BXumhOhfWaJy6Nt1yM4D6aI2utJh+oBMZQelv6DUES1EzKT9F31owr/0A+tNyA21o
61TA==
X-Gm-Message-State: AOAM533CqWief9bx7XF1X2vy8oNAg+EWgn3e1dBAet/Se+EiYp80cBCo
nmVMatSgh7rGCyBT6hMexJ7L8YNEBG+qiKdeBZQsVU0s45c=
X-Google-Smtp-Source: ABdhPJzKXO+Q2+VHmxnK7exe2ERJ0qmf/CtutLuOHxDtCltxqnV0bwzPulOkH6WHWa2Bcry69u/WkjvvF2jxwPOO3Oo=
X-Received: by 2002:a02:3712:: with SMTP id r18mr3088523jar.11.1619096490908;
Thu, 22 Apr 2021 06:01:30 -0700 (PDT)
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply
MIME-Version: 1.0
References: <13171428.RDIVbhacDa@spectre> <58222e6973413f903cc233b51df74b5593e80571.camel@gentoo.org>
<2113586.72vocr9iq0@spectre>
In-Reply-To: <2113586.72vocr9iq0@spectre>
From: "Wolfgang E. Sanyer" <wolfgangesanyer@gmail.com>
Date: Thu, 22 Apr 2021 09:01:19 -0400
Message-ID: <CACwN4Ly47PfUV6wnMKsfeGb0bmP+Mco4tobhg4Hhnb-xOqVMwA@mail.gmail.com>
Subject: Re: [gentoo-dev] Continuous integration on GURU
To: gentoo-dev@lists.gentoo.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Archives-Salt: 84f76072-c9db-4213-a9b7-cbcd794c81c7
X-Archives-Hash: 8e31e78b505a3eb1792d38716c55b3d7
On Thu, Apr 22, 2021 at 8:39 AM Agostino Sarubbo <ago@gentoo.org> wrote:
>
> On gioved=C3=AC 22 aprile 2021 12:02:20 CEST Micha=C5=82 G=C3=B3rny wrote=
:
> > Well, I suppose scanning the dev branch would be preferable over
> > the master branch. In reality, they are usually only a few hours apart
> > but it might be useful to know of new breakage in dev before it's merge=
d
> > to master.
> >
> > It would be ideal if you could do a switch when master and dev are
> > in sync, and just copy the state from master.
>
> Hi,
>
> I think that your approach could be generally valid but for this use case=
I'm
> against because of the following:
>
> 1) The approach is valid in cases like our github PRs and the bot that
> approves the commit. In this case, who moves the commit between branches =
does
> not know if the scan has been done or not.
>
> 2) I don't see the reason to scan against something that we don't know if=
will
> be the same in master branch
>
> 3) We are not doing a similar approach for ::gentoo so I don't see why do=
this
> for GURU since, after all, it is an overlay
>
> 4) Packages in master are supposed to be tested at least from 2 different
> people (who made the commit in dev and who moves the commit to master) so=
it
> means less bugspam
>
Perhaps another approach could be to add a third branch, "staging".
Any reviewers could move the appropriate ebuilds to "staging" once all
the reviews and discussions are done but before moving to "master"
In fact, probably a github action could be set up to automatically
move to "master" after the CI stuff passes.