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 7741E139694 for ; Tue, 25 Jul 2017 14:14:07 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id CFA6EE0D4E; Tue, 25 Jul 2017 14:14:01 +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 6F94AE0D20 for ; Tue, 25 Jul 2017 14:14:01 +0000 (UTC) Received: from pomiot (d202-252.icpnet.pl [109.173.202.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id 5762A3416F8; Tue, 25 Jul 2017 14:13:53 +0000 (UTC) Message-ID: <1500992029.795.17.camel@gentoo.org> Subject: Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts? From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-dev@lists.gentoo.org, wg-stable@gentoo.org, arch-leads@gentoo.org, alpha@gentoo.org, amd64@gentoo.org, amd64-fbsd@gentoo.org, arm@gentoo.org, arm64@gentoo.org, hppa@gentoo.org, ia64@gentoo.org, m68k@gentoo.org, mips@gentoo.org, ppc@gentoo.org, ppc64@gentoo.org, s390@gentoo.org, sh@gentoo.org, sparc@gentoo.org, x86@gentoo.org, x86-fbsd@gentoo.org Date: Tue, 25 Jul 2017 16:13:49 +0200 In-Reply-To: <20170724222223.6d359e47@sf> References: <20170724222223.6d359e47@sf> Organization: Gentoo Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-/g4rzs3l46t9TcYRQe+w" X-Mailer: Evolution 3.22.6 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 Mime-Version: 1.0 X-Archives-Salt: 17b9e781-c760-4528-806c-72c1952c9e47 X-Archives-Hash: 395b4f268739f934f7645f6f9727abc2 --=-/g4rzs3l46t9TcYRQe+w Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Before I start replying to specific bits, I think it would be reasonable to outline the flow of a keywording/stabilization bug. I would split it into 4 steps: S1. Someone (anyone) files a bug requesting it. S2. Someone (maintainer or OP) prepares a complete list of packages (including dependencies). S3. The maintainers approve (or reject) the request. S4. The arch teams process the request. Now, I think all considerations on automation should be from the perspective of those steps. On pon, 2017-07-24 at 22:22 +0100, Sergei Trofimovich wrote: > TL;DR > ----- >=20 > I see the problem of lagging stable and unstable trees as: >=20 > 1. lack of automation > 2. lack of manpower >=20 > The PROPOSAL to solve the '1. automation' part is to draft > a new GLEP. If there is any interest (I assume there is!) I'll start one. > Let's call that fufure 'life of KEYWORDS'. It will cover: >=20 > - Update on GLEP-40 ("x86 stabilization can do only x86@ team") > to allow package maintainers to do ARCH=3Dx86 stabilization. > It will be an arch-agnostic way: each arch will have minimal requiremen= ts > to setup environment suitable for stabilization and keywording: > CFLAGS to have, hardware required, whatever else is practical. I'd dare say arch-specific policies are arch team's business. The replacement for GLEP 40 should set some base rules but allow arch teams to override them. I feel like this is going towards 'anybody can do keywording / stabilization'. I'd rather not go this route right now, and just let arch teams recruit people as they see fit. - Formalize list of stable arches as such (will be covered by > 'arches.desc' GLEP) > - Formalize what is a "stable arch". In short: > - arch is marked as such in 'arches.desc' > - performs most of STABLEREQ/KEYWORDREQ or gives rationale > why progress can't be easily done before 90-days timeout Just to be clear, is this going into your GLEP? I'd prefer if the 'arches.desc' GLEP was kept purely technical wrt the file format and not covered policies. Oh, and when you are doing the new GLEP, don't forget to mention ALLARCHES. >=20 > - Formalize and automate process of dropping keywords for timed out > STABLEREQ/KEYWORDREQ requests. > - Automate process of restoring dropped KEYWORDS due to bumps > adding new unkeyworded dependencies. repoman already complains > about those. What is left is to grab them in batches time to time > and handle those as if those were KEYWORDREQ. This might require making more proactive use of '-foo' keywords (QA tools complain about them right now), or some other way of indicating 'I have tested it and it won't work'. Or at least checking for WONTFIX bugs. > - File more automated STABLEREQs to rely less on lazy maintainers > (I am example of lazy maintainer not siling STABLEREQs enough). What I'm a little worried about is that this would proactively try to stabilize package versions that are not suitable for stabilizations, e.g. upstream development branch. Without expecting too much guesswork on the scripting, I'd say it'd be reasonable enough if it checked for WONTFIX bugs to avoid filing the same rejected bug again. Those are the solution for S1 and maybe partially S2 in my flow above. What I'd add for S2: - make stable bot more proactive on complaining about package lists with missing dependencies -- right now it waits for arch teams to be CC-ed; given this might require packages from other maintainers, it'd be better if it tried investigating earlier (guessing keywords from existing package if they are not explicitly given in package list). > - Formalize which STABLEREQ/KEYWORDREQ can be done automatically > by arch teams (or maybe anyone else having the hardware!). > In short: anything not marked as "Runtime testing required" > on bugzilla and not having any blocker bugs. And that's S4. I'd focus on leaving it for the arch teams to have a final say but the 'runtime testing required' part is reasonable. All that said, I think there's one more important part of tooling we're missing right now: reverse mapping of packages into keywording / stabilization bugs. In other words, having a package app-foo/bar, I'd like to know if its keywording or stabilization has been requested anywhere. In other words, if I should include it in my bug, or just link to some other bug, or... --=20 Best regards, Micha=C5=82 G=C3=B3rny --=-/g4rzs3l46t9TcYRQe+w Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQKmBAABCgCQFiEEbbsHzE8NrQbqCv5BsHoa6u+0Rk4FAll3Uh1fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDZE QkIwN0NDNEYwREFEMDZFQTBBRkU0MUIwN0ExQUVBRUZCNDQ2NEUSHG1nb3JueUBn ZW50b28ub3JnAAoJELB6GurvtEZORpkP/0291aI9oc2NFSXMH9kQWRV4R+v5scE9 zOdLs8PAM+5IB0YSv86TKf5oGHma40F2dDirg5OeCrDXGZ+I3jfNyH/iiJZQaF4V CKQ39JpDFV7UntkO2ArnBokRn/Ug3oyrXPBva5bcXH3EQwZTRYfQZ/n44yseBeNj kF0fizC/fGU53FhN8pltEXaAqz524/sCcy3iSI12CHQS9GplHX6qvJK2Ng/uR7pZ zUT6BYLKf45bCa22Kojl2F5rg9stfN6BiKB9YANqpL2xW8aAazE9nTZLwy9QyXuy 20LexZFlPnG02PzRIWLwOs7zOGAL/4HifzBs61xtz5kwW61tuOcWW2fK5p65/aUF ua0glNQYEL63bBNzW22EQ2yB5e3s56Jl7kivEcDPuCctIM0DARHZdHVffXHNYve4 kX6Fy27dg5XnBD1lAhssQHIid1fVvVX34SOuhIS5iup82kplO4WFdXbhrbfy2vFf yrZky3QDmXWGJgSakm4laXVU1CkEOZtGA9puMEzfdwFq5G3kNL8ZhysNDt7QTW4G D6ialpJ2zgKbXLeC+pvkBS1bbkbXdJcOufdR8fVssBgJJsf5PRGsIosWcEc1hBuc E/dc01spocHtZ32f+mVe832LeSROl4OmUPNiQvIJcXGVNxLfeczx+9MuAgX70qZD ELQ3OUsX0TtX =Hx0L -----END PGP SIGNATURE----- --=-/g4rzs3l46t9TcYRQe+w--