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