On Fri, 09 Aug 2013 17:25:10 +0200 hasufell <hasuf...@gentoo.org> wrote:
> No, that is definitely not how stabilization works and I was told > something different during my recruitment process. > > * _stable_ (as in... it works on different setups... this is already > not true for gnome) Current documentation and ebuild policy does not reflect the different setups bit; that is, it merely mentions that it must be widely tested but it is not clear whether that includes different setups or not. http://devmanual.gentoo.org/keywording/#moving-from-~arch-to-arch http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1#doc_chap4_sect4 Even stronger, the ebuild policy mentions in the same section that "It is up to the maintainer of the package to deem which versions are stable or if development versions should be in package.mask or left in ~arch."; and in this sense, I think only instances like QA, security, *Rel and the Council stand above that. So, under strict ebuild policy, we can not block stabilization without calling one of those instances with an objection to the change; we both know that a lot of people don't really follow this anymore, but it is still written down and should be corrected if we want this to be different. I'm really surprised to find the policy to state this rule. > I don't care what people think about OpenRC or systemd. I support > BOTH. If a package only supports one, that is a BUG (and in this > case... a regression even). You keep repeating this, I'm yet to see agreement on this; so "maybe". > This is similar to gcc vs clang. Clang is not ready yet to be used > system-wide, so gcc is still our main implementation and the default > (as in: shipped in stage3). Even if clang was stable... a package > that does not compile with gcc would never be allowed to go stable. > We want it to work on BOTH compilers. The difference between systemd and Clang is that systemd is marked stable whereas Clang is not; so, you can in fact not stabilize a package because Clang as a dependency is not yet stable. The difference between OpenRC and GCC is that OpenRC is not selected in @system whereas GCC is selected in @system; so, you can replace OpenRC whereas you can't replace GCC until @system adjusts. You are comparing apples and eggs here. GCC is currently a core requirement, OpenRC is not and thus replaceable. > If you can't make that happen, then that's okay. But don't attempt to > call that package stable then. It's not. What does incompatibility have to do with stability? -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
