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.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 5179815800A for ; Mon, 17 Jul 2023 17:24:43 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 68387E0887; Mon, 17 Jul 2023 17:24:39 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 2E627E086F for ; Mon, 17 Jul 2023 17:24:39 +0000 (UTC) References: User-agent: mu4e 1.10.4; emacs 29.0.92 From: Sam James To: gentoo-dev@lists.gentoo.org Cc: Sam James , Arthur Zamarin , Tim Harder Subject: Re: [gentoo-dev] Package stabilization groups Date: Mon, 17 Jul 2023 17:37:44 +0100 In-reply-to: Message-ID: <87lefebgdr.fsf@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-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Archives-Salt: 8d4d8c1a-4754-4585-82dd-090a38bf018b X-Archives-Hash: b7e1f6b640a391e93d08951e446efecf --=-=-= Content-Type: text/plain Matt Turner writes: > Hello, > > Many of us have started using `pkgdev bugs` to file stabilization > bugs. It works well (Thanks Arthur!) and I encourage everyone to give > it a try. > > Where possible, it files one stabilization bug per package. This makes > arch testers' jobs easier and makes the task easier to automate. > > But sometimes we do want to stabilize packages together. For example > major versions of x11-wm/mutter and gnome-base/gnome-shell are tied > together. If a new mutter is stabilized without the new gnome-shell, > the tree will still be consistent, but emerge -u @world will warn > users that the mutter upgrade is blocked. > Big fan of the idea & very much in support of it. This also serves to give us logical groupings of packages which are closely related and should be bumped together. > There was some brief discussion on IRC about how to document these > groupings, and two main ideas were suggested: > > - add a field to metadata.xml to specify the group by an arbitrary name. > E.g. > Each package in the group would specify the same value of name="..." > > - maintain the groups in a separate place (similar to portage @sets). > > Can anyone think of particular advantages or disadvantages to one > solution versus the other? Any other (better) ideas? > When we discussed this a few months ago on IRC, I also brought up a related point: [2023-05-02T18:38:51+0100] <@sam_> do we want to repeat the group members in each member, or do tools need to scan for each thing? [2023-05-02T18:39:07+0100] <@sam_> i.e. does each member have ..., or do we do