On 16/07/2023 17.57, Matt Turner wrote:
> Hello,
> 
> Many of us have started using `pkgdev bugs` to file stabilization
> bugs. It works well (Thanks Arthur!) and I encourage everyone to give
> it a try.

Gladly :) You can semi-blame mgorny for the creation of `pkgdev bugs`,
because I started to file stablereqs for @python packages, and at some
point it was too tiring and repetitive, so I was brought to the drawing
table to think of a solution.

> Where possible, it files one stabilization bug per package. This makes
> arch testers' jobs easier and makes the task easier to automate.
> 
> But sometimes we do want to stabilize packages together. For example
> major versions of x11-wm/mutter and gnome-base/gnome-shell are tied
> together. If a new mutter is stabilized without the new gnome-shell,
> the tree will still be consistent, but emerge -u @world will warn
> users that the mutter upgrade is blocked.
> 
> There was some brief discussion on IRC about how to document these
> groupings, and two main ideas were suggested:
> 
> - add a field to metadata.xml to specify the group by an arbitrary name.
>   E.g. <stable-group name="..."/>
>   Each package in the group would specify the same value of name="..."
> 
> - maintain the groups in a separate place (similar to portage @sets).
> 
> Can anyone think of particular advantages or disadvantages to one
> solution versus the other? Any other (better) ideas?

Let me list some things as advantages to each one (since I see an
advantage to one as disadvantage to other).

Advantages of field in metadata.xml:

- local to package, easier to not miss. Easier to follow for the maintainer.

- easier to find which group the current package relates to

Advantages to group files:

- easier to index (one file listing all children, instead of searching
across repo who defines it)

- easier to not repeat group. In the metadata field it might happen to
repeat, less likely since it is easy to search, but similar group names
might be created, merging them into one by mistake, or creating very
similar names and mistaking them. When we have a single file, it is
easier to see the whole picture and verify things.

- since this is compressed information (special files instead of spread
over repo), we could load all of them into app's cache, and make all
computation easier.

- enables an easier syntax as `pkgdev bugs @group1` to file a single bug
for all of them. In Gnome's case as an example, we could have "gnome1",
"gnome2", "gnome3", "gnome4", etc - groups standing for multiple
"layers/stages" of stabilizing, and then you could just file `pkgdev
bugs @gnome{1..4}` to file "at one click" the whole gnome stablereqs.

> Thanks,
> Matt


Now I'll speak from the point of implementer of `pkgdev bugs`. For me I
think both approaches are good, but I would prefer the latter over the
former. Nicer syntax, easy cache of all groups, easier to solve the
"graph problems" in the tool.

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