From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Re: The meaning of attributes in repositories.xml?
Date: Fri, 28 Mar 2025 16:31:58 -0000 (UTC) [thread overview]
Message-ID: <pan$250b3$555773d$71317638$4d600b3c@cox.net> (raw)
In-Reply-To: 541f2b74b3d6aea9283333bd7b3a129d025db551.camel@gentoo.org
Michał Górny posted on Fri, 28 Mar 2025 14:04:32 +0100 as excerpted:
> On Fri, 2025-03-28 at 08:23 +0000, Duncan wrote:
>> Status:
>>
>> * "Official" status meant managed by an official Gentoo project or
>> developer (who had gone thru the usual vetting process), […]
>>
>> * "Unofficial" status had rather less security-trust and was intended
>> for "ordinary users". […]
> GURU specifically falls on the edge between these two definitions.
> On one hand, by definition it is entirely maintained by users.
> On the other, it is an official Gentoo project, and goes through some
> kind of vetting process (i.e. Gentoo devs approve TCs, TCs and devs
> review changes before pushing them to the main branch).
Hmm... Yes, I was deliberating about that in my thoughts as I posted too,
but decided to leave it alone. Now I'm wondering again...
Adding to ulm's three-level idea (which I see you already WFMed), maybe:
* Core: Gentoo main tree only (for now)
* Official: Gentoo project/dev repos (and I like his opt-in, can choose to
be unofficial)
+* Semi-official: Guru. But I'm not happy with the name. Maybe keep it
simple, call the level Guru as well (after all core just has one repo in
it ATM, too), and just accept that guru level might well include more than
just the guru repo in the future?
* Unofficial: Everything else
With or without semi-official, so far this does seem the general
consensus. But for three-level guru really is a square peg in a round
hole, and whatever demoting/promoting occurs to make it fit would seem
rather forced and out-of-place.
More so, for the purposes of EAPI deprecation and removal consideration
I'd draw the line to include guru and exclude unofficial, which would
either practically force guru to official in the three-level plan, or make
it even /more/ out-of-place in unofficial, as the single exception.
Which leans me toward four-level, except for the practical consideration
that once it passes three where might it stop in the future as there's
always new exceptions and three's a nicer place to draw the line than
four. Maybe get rid of core level and just put the main tree in official
too, thus leaving us with three levels /including/ guru?
Really I'd be satisfied with any of [o/u (just two level), c/o/u, c/o/g/u,
o/g/u] (and enforcing whichever choice), much more so than with removing
that attribute entirely as to me that'd be an undesirable step backward.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
next prev parent reply other threads:[~2025-03-28 16:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-28 4:27 [gentoo-dev] The meaning of attributes in repositories.xml? Michał Górny
2025-03-28 8:15 ` [gentoo-dev] " Anna Vyalkova
2025-03-28 8:59 ` Ionen Wolkens
2025-03-28 8:23 ` Duncan
2025-03-28 13:04 ` Michał Górny
2025-03-28 16:31 ` Duncan [this message]
2025-03-30 14:37 ` Gerion Entrup
2025-03-28 11:59 ` [gentoo-dev] " Ulrich Müller
2025-03-28 12:57 ` Michał Górny
2025-03-28 16:51 ` Ulrich Müller
2025-03-28 17:19 ` Michał Górny
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='pan$250b3$555773d$71317638$4d600b3c@cox.net' \
--to=1i5t5.duncan@cox.net \
--cc=gentoo-dev@lists.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