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 92ACB158004 for ; Mon, 24 Jul 2023 13:59:11 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id EA466E08A5; Mon, 24 Jul 2023 13:59:07 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id A43FEE0885 for ; Mon, 24 Jul 2023 13:59:07 +0000 (UTC) Received: by mail-yb1-f170.google.com with SMTP id 3f1490d57ef6-d0e009433c4so1544676276.2 for ; Mon, 24 Jul 2023 06:59:06 -0700 (PDT) X-Gm-Message-State: ABy/qLb/ktNEE+yQM8baktSaJvF0paHuIGenvguD9rd6qolna7q3vYv9 eEju1SA+GuXdbkw6KgjuAhbIT/HFY4UGjQuFVH8= X-Google-Smtp-Source: APBJJlHx3KaXdL4rziAnDJjS31WoxdwAa9OmYA44GmQnAiHoEtpJnaJdDEUR+ooQePWf8WbWczHMm+aAPrgVvvpkgc8= X-Received: by 2002:a25:abea:0:b0:d10:e6a2:1947 with SMTP id v97-20020a25abea000000b00d10e6a21947mr2462090ybi.19.1690207144968; Mon, 24 Jul 2023 06:59:04 -0700 (PDT) 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 References: <20230719161117.2561126-1-mattst88@gentoo.org> <49ec2455-9055-c9f7-9619-723f0d2a7ebf@gentoo.org> In-Reply-To: <49ec2455-9055-c9f7-9619-723f0d2a7ebf@gentoo.org> From: Matt Turner Date: Mon, 24 Jul 2023 09:58:53 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: [gentoo-dev] Re: [RFC PATCH] metadata: Add gnome package stabilization groups To: Arthur Zamarin Cc: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 2d5776c7-968d-4f17-b421-39299219c912 X-Archives-Hash: a13502a06106fb3f17c296606172cfb2 On Fri, Jul 21, 2023 at 2:22=E2=80=AFPM Arthur Zamarin wrote: > > On 19/07/2023 19.10, Matt Turner wrote: > > Signed-off-by: Matt Turner > > --- > > Feel free to bikeshed the location, structure, file-format, etc. > > > > metadata/stabilization-groups/gnome/evolution | 3 +++ > > metadata/stabilization-groups/gnome/glib | 3 +++ > > metadata/stabilization-groups/gnome/gnome-shell | 4 ++++ > > metadata/stabilization-groups/gnome/gobject-introspection | 2 ++ > > metadata/stabilization-groups/gnome/sysprof | 3 +++ > > metadata/stabilization-groups/gnome/vala | 2 ++ > > metadata/stabilization-groups/gnome/vte | 3 +++ > > 7 files changed, 20 insertions(+) > > create mode 100644 metadata/stabilization-groups/gnome/evolution > > create mode 100644 metadata/stabilization-groups/gnome/glib > > create mode 100644 metadata/stabilization-groups/gnome/gnome-shell > > create mode 100644 metadata/stabilization-groups/gnome/gobject-introsp= ection > > create mode 100644 metadata/stabilization-groups/gnome/sysprof > > create mode 100644 metadata/stabilization-groups/gnome/vala > > create mode 100644 metadata/stabilization-groups/gnome/vte > > > > So semi-formalizing it before I implement parsing it in pkgcore: > > 1. everything is located under "metadata/stabilization-groups/" > 2. We search recursively as much as needed, so all files are included in > any depth. > 3. Group name plays similarly to path, so here the group name would be > "@gnome/vte" (at least for `pkgdev bugs` invocations). By using full > path, we are safe from name collisions. > 4. The file itself uses similar format to our various profiles files. > Ignore white-spaces before and after, "#" as a comment. Only one > "cat/pkg" per line. > 5. I think for now we can go without mandatory copyright header... > > > > How it will affect `pkgdev bugs` invocations? I'll use your sets as > example. Let's say our invocation is `pkgdev bugs dev-libs/glib > @gnome/vala`. > > - if a set is passed (anything starting with @), replace it with all the > contents of that set (so "@gnome/vala" equals to "dev-libs/vala-common > dev-lang/vala"). > > - Drop every package from the pkglist whose latest matching package to > the restricts expression is already latest (so nothing better to do). > > - pkgdev bugs builds the full graph as it does today. Let's say it > decided it needs to also add "dev-util/glib-utils". > > - For every defined set, all the packages included in graph and in the > set are merged into one bug. This means we would get one bug for > "@gnome/vala" ("dev-libs/vala-common dev-lang/vala") and one bug for > "@gnome/glib" ("dev-libs/glib dev-util/glib-utils"). Notice that it > didn't add the other package in that set ("dev-util/gdbus-codegen") > since it wasn't requested or required. > > Does this flow seems logical and flexible enough? I don't think auto > adding whole set if any one of it's package is required is a good idea > since it might explode? If folks want to stable the whole set, explicit > pass it as arg in the invocation. > > Do note that I'm open to other flows and usages, everything is open for > me (I didn't start to implement it, just scratches in my notebook). Yeah, this sounds spot on to me. Thanks Arthur!