From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 0DAAB1581EE for ; Fri, 28 Mar 2025 16:32:53 +0000 (UTC) Received: from lists.gentoo.org (bobolink.gentoo.org [140.211.166.189]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) (Authenticated sender: relay-lists.gentoo.org@gentoo.org) by smtp.gentoo.org (Postfix) with ESMTPSA id E69C03431B8 for ; Fri, 28 Mar 2025 16:32:52 +0000 (UTC) Received: from bobolink.gentoo.org (localhost [127.0.0.1]) by bobolink.gentoo.org (Postfix) with ESMTP id 06D561104BA; Fri, 28 Mar 2025 16:32:08 +0000 (UTC) Received: from ciao.gmane.io (ciao.gmane.io [116.202.254.214]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by bobolink.gentoo.org (Postfix) with ESMTPS id 405B01104B1 for ; Fri, 28 Mar 2025 16:32:07 +0000 (UTC) Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1tyCcn-00085S-6r for gentoo-dev@lists.gentoo.org; Fri, 28 Mar 2025 17:32:05 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: The meaning of attributes in repositories.xml? Date: Fri, 28 Mar 2025 16:31:58 -0000 (UTC) Message-ID: References: <541f2b74b3d6aea9283333bd7b3a129d025db551.camel@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit User-Agent: Pan/0.162 (Pokrosvk; 0a913ba36f6ce7a58fc950ca885cd9fb4c87f016) X-Archives-Salt: a2afc181-4922-42dc-be21-cf1d90e0c37f X-Archives-Hash: 909cc57f55c8da058b2734f7ebcb947f 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