From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 9726D1382C5 for ; Thu, 22 Apr 2021 12:39:13 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D6025E08ED; Thu, 22 Apr 2021 12:39:10 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (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 660E2E08E0 for ; Thu, 22 Apr 2021 12:39:10 +0000 (UTC) From: Agostino Sarubbo To: gentoo-dev@lists.gentoo.org Cc: guru@gentoo.org, guru-devs@gentoo.org, =?utf-8?B?TWljaGHFgiBHw7Nybnk=?= Subject: Re: [gentoo-dev] Continuous integration on GURU Date: Thu, 22 Apr 2021 14:39:02 +0200 Message-ID: <2113586.72vocr9iq0@spectre> In-Reply-To: <58222e6973413f903cc233b51df74b5593e80571.camel@gentoo.org> References: <13171428.RDIVbhacDa@spectre> <58222e6973413f903cc233b51df74b5593e80571.camel@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail 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 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: 5d2ce841-e4c5-4fe0-832f-2d42eda6a10e X-Archives-Hash: 3e38ec0eb32724e133cfd595caa6c579 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 merged > to master. >=20 > 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=20 against because of the following: 1) The approach is valid in cases like our github PRs and the bot that=20 approves the commit. In this case, who moves the commit between branches do= es=20 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 w= ill=20 be the same in master branch 3) We are not doing a similar approach for ::gentoo so I don't see why do t= his=20 for GURU since, after all, it is an overlay 4) Packages in master are supposed to be tested at least from 2 different=20 people (who made the commit in dev and who moves the commit to master) so i= t=20 means less bugspam > One more thing: might be a good idea to consider splitting some > of the 'big' trackers (like CFLAGS) between Gentoo and GURU. I think > solving these bugs in GURU has lower priority than in Gentoo. I think that trackers like CFLAGS/LDFLAGS are here to track how many packag= es=20 have the problem. I don't see it like (for example) the gcc-porting tracker= =20 that gives the idea about how much packages need a fix and how much package= s=20 need to be last-rited Agostino