public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Ulrich Mueller <ulm@gentoo.org>
To: Arthur Zamarin <arthurzam@gentoo.org>
Cc: gentoo-dev@lists.gentoo.org,  Matt Turner <mattst88@gentoo.org>,
	 Sam James <sam@gentoo.org>,  Tim Harder <radhermit@gentoo.org>
Subject: Re: [gentoo-dev] Package stabilization groups
Date: Sun, 16 Jul 2023 20:11:13 +0200	[thread overview]
Message-ID: <uv8ejloam@gentoo.org> (raw)
In-Reply-To: <19edc9b0-6f85-cd19-48ed-d2b7152d256a@gentoo.org> (Arthur Zamarin's message of "Sun, 16 Jul 2023 21:04:35 +0300")

[-- Attachment #1: Type: text/plain, Size: 1492 bytes --]

>>>>> On Sun, 16 Jul 2023, Arthur Zamarin wrote:

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

Can't we do the same that we do for local use flags? Namely, define them
in metadata.xml, but collect them in one central location?

Ulrich

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]

  reply	other threads:[~2023-07-16 18:11 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-16 14:57 [gentoo-dev] Package stabilization groups Matt Turner
2023-07-16 15:15 ` Fabian Groffen
2023-07-16 15:29   ` Matt Turner
2023-07-16 18:04 ` Arthur Zamarin
2023-07-16 18:11   ` Ulrich Mueller [this message]
2023-07-16 18:13     ` Arthur Zamarin
2023-07-17 13:50   ` Matt Turner
2023-07-17 16:39     ` Arthur Zamarin
2023-07-18  3:42       ` Oskari Pirhonen
2023-07-17 16:37 ` Sam James
2023-07-17 17:34   ` Arthur Zamarin
2023-07-17 18:14     ` Ionen Wolkens
2023-07-24 13:22 ` Agostino Sarubbo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=uv8ejloam@gentoo.org \
    --to=ulm@gentoo.org \
    --cc=arthurzam@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    --cc=mattst88@gentoo.org \
    --cc=radhermit@gentoo.org \
    --cc=sam@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox