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