[gentoo-dev] Re: [RFC PATCH] metadata: Add gnome package stabilization groups

[Matt Turner <mattst88@gentoo.org>]

On Fri, Jul 21, 2023 at 2:22 PM Arthur Zamarin <arthurzam@gentoo.org> wrote:
>
> On 19/07/2023 19.10, Matt Turner wrote:
> > Signed-off-by: Matt Turner <mattst88@gentoo.org>
> > ---
> > 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-introspection
> >  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!