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

[Arthur Zamarin <arthurzam@gentoo.org>]

[-- Attachment #1.1: Type: text/plain, Size: 3298 bytes --]

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).

-- 
Arthur Zamarin
arthurzam@gentoo.org
Gentoo Linux developer (Python, pkgcore stack, Arch Teams, GURU)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]