m68k, s390, sh As you all know, by our 20130917 council decision these arches should no longer have stable keywords. Since we never formally decided about the exact way to go ahead (the "aging out policy" was just what came out of informal discussion between a few people), and since Mike has been merrily stabling recently: Unless a majority of you objects here and now, I'll start dropping these stable keywords to ~arch with category commits in all ebuilds tree-wide in 48h. Vote no to object. (As a matter of record creffett as qa lead has pinged Mike on irc about the stabling. I am not aware of any response.)
CCing affected arch teams.
I just want to point that we could have 2 way to do it: 1)Make one commit for arches that means that every package will have the right changelog, e.g. "Downgrade to ~sh". 2)Make only one commit that means that every package will have a changelog like: "Downgrade to ~sh/~s390/~m68k" so I could have a package that have the sh keyword and not the m68k keyword but the changelog will mention unconditionally m68k. What do you think/prefer?
For reference, here's the mail I sent to Mike a few hours ago. From: "Andreas K. Huettel" <dilfridge@gentoo.org> To: Mike Frysinger <vapier@gentoo.org> Cc: qa@gentoo.org, Gentoo Council <council@gentoo.org> Subject: stable keywords on m68k, s390, sh Date: Fri, 17 Jan 2014 15:10:38 +0100 Message-ID: <10455042.L5FUp2tGQs@pc1011300184> Dear Mike, in its September 2013 session the Gentoo council decided to downgrade m68k, s390, and sh to ~arch-only architectures. As far as I can remember, in the discussion preceding this decision noone ever spoke up for these arch teams. The decision was unanimous for m68k and s390, and with one opposing vote for sh [1]. You have recently stabled a lot of packages on these arches, and also reverted the profile make.defaults of s390 to accept a stable keyword only by default. The latter I have undone again, since there is no point in using this distinction in any way in the main portage tree now. Please stop the stabilizations on m68k, s390, sh. They are just plain pointless (noone will care about the deptree, no requests will be filed), and it's also not really productive to silently oppose a community decision. At least, please dont set the profile to accept stable keywords again. The stable keywords are phasing out, if that doesn't work, at some point they may be removed in one go [2]. If you have good reasons why m68k, s390, sh should be stable arches, please convince us. There is no decision that cannot be reverted given good enough arguments. Best, Andreas [1] http://www.gentoo.org/proj/en/council/meeting-logs/20130917-summary.txt [2] https://bugs.gentoo.org/show_bug.cgi?id=498332
(In reply to Andreas K. Hüttel from comment #0) > m68k, s390, sh > > As you all know, by our 20130917 council decision these arches should no > longer have stable keywords. > > Since we never formally decided about the exact way to go ahead (the "aging > out policy" was just what came out of informal discussion between a few > people), and since Mike has been merrily stabling recently: > > Unless a majority of you objects here and now, I'll start dropping these > stable keywords to ~arch with category commits in all ebuilds tree-wide in > 48h. I want to go on the record and say I fully support this. > > Vote no to object. > > (As a matter of record creffett as qa lead has pinged Mike on irc about the > stabling. I am not aware of any response.) I am also not aware of any response.
responding here because using private aliases to discuss is wrong (we have qa & council mailing lists but apparently those were ignored). the issue with the arches was that they weren't keeping up with stable requests. that's not really debatable. however, it does not follow that the arch maintainers should be restricted to only unstable keywords. the issue really boils down to package maintainers: (1) developers getting blocked/annoyed by `repoman commit` (2) allowing dropping of old ebuilds that contain stable keywords (and thus moving an arch back to unstable-only by a package maintainer) (3) not paying attention to the KEYWORDS when adding new dependencies (somewhat like point 1, but worth noting independently) none of those requirements block minor arches from using stable keywords. the fact that an arch has been labeled "minor" means that their profiles are no longer marked stable in profiles.desc which means repoman no longer complains (point 1 and point 3), and that maintainers may ignore them when dropping old ebuilds (point 2). the months since only prove that this is working as i describe. maintainers have been dropping back to ~arch and breaking the stable tree. yet commits/updates continue to flow unabated. this has nothing to do with the ACCEPT_KEYWORDS setting as repoman doesn't use that. it's purely based on profiles.desc. there is way too much churn in ~arch to be able to sanely keep the core packages viable not to mention instability. the stable keywords are needed at least to keep stage building and basic developer systems running.
Thanks Mike. Not doing anything for the moment; I'm waiting for opinions.
I don't mind stable keywords being around, as long as they don't interfere with package maintainers' workflow. Points (1) to (3) of comment 5 seem to address this. Also profiles for these architectures should retain dev or exp status. However, the council decision was to "drop all ebuilds to unstable keyword" so this would have to be revised. I suggest that any further action (of both sides!) is shelved until then.
(In reply to SpanKY from comment #5) > none of those requirements block minor arches from using stable keywords. > the fact that an arch has been labeled "minor" means that their profiles are > no longer marked stable in profiles.desc which means repoman no longer > complains (point 1 and point 3), and that maintainers may ignore them when > dropping old ebuilds (point 2). I didn't appreciate this point when I voted in favor of dropping to ~arch. repoman does have a -d and -e option for when you *do* want to include these "minor" arches but otherwise they dev/exp are ignored. (In reply to Ulrich Müller from comment #7) > I don't mind stable keywords being around, as long as they don't interfere > with package maintainers' workflow. Points (1) to (3) of comment 5 seem to > address this. Also profiles for these architectures should retain dev or exp > status. I was primarily concerned about this point, namely burdoning maintainers with having to chase around minor arch teams to stabilize their packages, or worse, stabilize dependencies on their packages. I'm okay with revisiting this in light of a better understanding. (In reply to SpanKY from comment #5) > there is way too much churn in ~arch to be able to sanely keep the core > packages viable not to mention instability. the stable keywords are needed > at least to keep stage building and basic developer systems running. Slightly off topic: I've been building mips uclibc stages without stable and having to mask in the profiles. I wonder if we can't go the other way with mips and re-add stable keywords *just* for the @system packages.
(In reply to Anthony Basile from comment #8) > (In reply to SpanKY from comment #5) > > none of those requirements block minor arches from using stable keywords. > > the fact that an arch has been labeled "minor" means that their profiles are > > no longer marked stable in profiles.desc which means repoman no longer > > complains (point 1 and point 3), and that maintainers may ignore them when > > dropping old ebuilds (point 2). > > I didn't appreciate this point when I voted in favor of dropping to ~arch. > repoman does have a -d and -e option for when you *do* want to include these > "minor" arches but otherwise they dev/exp are ignored. I didn't either. > > (In reply to Ulrich Müller from comment #7) > > I don't mind stable keywords being around, as long as they don't interfere > > with package maintainers' workflow. Points (1) to (3) of comment 5 seem to > > address this. Also profiles for these architectures should retain dev or exp > > status. > > I was primarily concerned about this point, namely burdoning maintainers > with having to chase around minor arch teams to stabilize their packages, or > worse, stabilize dependencies on their packages. I'm okay with revisiting > this in light of a better understanding. Point 2 also addresses my concern. It means that once an arch is marked dev or exp in profiles.desc, maintainers are allowed to ignore this arch when removing old versions of a package.
(In reply to Anthony Basile from comment #8) > Slightly off topic: I've been building mips uclibc stages without stable and > having to mask in the profiles. I wonder if we can't go the other way with > mips and re-add stable keywords *just* for the @system packages. Since mips is marked exp in profiles.desc, going along with point 2, if we allow stable keywords, the arch team would be able to stabilize packages, but the maintainers can remove those stable packages when they are old and when all of the major arch's have stabled a newer version.
(In reply to Anthony Basile from comment #8) yeah, you can check the extra profiles with -d/-e. locally i changed these profiles back to "stable" and have seen enough breakage that i suspect devs don't run with -d/-e else they'd be more proactive in dropping back to ~arch. this doesn't mean that i think we should encourage things to remain broken in "dev". so we should probably migrate the minor arches from "dev" to "exp" and encourage people to stay more on top of things in "dev". i see that as being the stepping stone between "exp" (we know it's not uncommon to be broken, but we're OK with that) and "stable". but if no one uses -d because "dev" is commonly broken, then it's kind of pointless to have both "dev" & "exp". much of this boils down to these files being rarely used/examined so there isn't any real written policy behind it. i love the devmanual entry on the topic actually: http://devmanual.gentoo.org/profiles/profiles.desc/index.html the portage(5) documentation is purely technical -- it describes only the format. i'll put together some content and bounce it to gentoo-dev@ before pushing to profiles.desc. the portage(5) man page should stick to the technical and simply refer people to the file itself for policy.
(In reply to Anthony Basile from comment #8) i would love to see mips stable return
(In reply to SpanKY from comment #12) > (In reply to Anthony Basile from comment #8) > > i would love to see mips stable return yeah okay. on my todo. what do you recommend I start with @system?
(In reply to Anthony Basile from comment #13) i would start with catalyst. whatever it takes to make it build stage1/2/3.
(In reply to SpanKY from comment #14) > (In reply to Anthony Basile from comment #13) > > i would start with catalyst. whatever it takes to make it build stage1/2/3. we're building stage1/2/3 with catalyst now. hwoarang is doing the glibc stuff and i'm doing uclibc. I'll discuss this with the mips team and just do it.
(In reply to SpanKY from comment #5) > there is way too much churn in ~arch to be able to sanely keep the core > packages viable not to mention instability. the stable keywords are needed > at least to keep stage building and basic developer systems running. This is totally true. I was literally never once able to build a mips (~mips) stage from a snapshot of portage without hacking it up with various non-mips related fixes that I found in bugzilla. (In reply to Anthony Basile from comment #8) > Slightly off topic: I've been building mips uclibc stages without stable and > having to mask in the profiles. I wonder if we can't go the other way with > mips and re-add stable keywords *just* for the @system packages. I suggested doing this a few years ago right after I joined the team and was the only active member. Some people on gentoo-dev@ didn't think it was possible to keep a stable @system with only one person. They were probably right, and probably saved me a big headache. (In reply to Anthony Basile from comment #15) > (In reply to SpanKY from comment #14) > > (In reply to Anthony Basile from comment #13) > > > > i would start with catalyst. whatever it takes to make it build stage1/2/3. > > we're building stage1/2/3 with catalyst now. hwoarang is doing the glibc > stuff and i'm doing uclibc. I'll discuss this with the mips team and just > do it. He meant start by stabilizing the packages necessary to build stages with catalyst, not that there's actual catalyst work.
Having the stable keywords around for @system and related sounds pretty much reasonable for me, and we should probably just document or formalize it along the lines of comments 5-9 somehow. [And move this discussion back to a/any mailing list.] One small detail, I personally would prefer if the profile make.defaults still sets ACCEPT_KEYWORDS="arch ~arch", for the simple reason that this is the default setting we advertise to users, and it would keep stable=stable and dev/exp=unstable consistent. Everyone should be able to override that in own make.conf easily to ACCEPT_KEYWORDS=arch if I'm not mistaken. (But then this override also would work the other way around.)
My 2 cents about idea of adding stable keywords for MIPS - i hope we do this only for @system packages for now. I mean - if we do this, we would NOT allow to add stable mips keywords to other packages and still consider MIPS as unstable-only arch for majority of packages. Cause, reasons for such situation is pretty clear for me and i do not see why we should change this, except for ease stage building(where stable keywords saves releng time, as was said earlier).
> (In reply to Anthony Basile from comment #15) > > (In reply to SpanKY from comment #14) > > > (In reply to Anthony Basile from comment #13) > > > > > > i would start with catalyst. whatever it takes to make it build stage1/2/3. > > > > we're building stage1/2/3 with catalyst now. hwoarang is doing the glibc > > stuff and i'm doing uclibc. I'll discuss this with the mips team and just > > do it. > > He meant start by stabilizing the packages necessary to build stages with > catalyst, not that there's actual catalyst work. I did understand it that way. I didn't express myself well. What I meant was we have all the stages building fine with the system packages at ~mips keywording already. So just converting ~mips to mips in all the latest @system packages would work. ie. its pretty easy. (I have to check but I'm pretty sure about this). I'll open another bug and suggest what packages to stabilize and see what mips peep think.
OK I guess we should just move this back on the next meeting agenda then, 'cause right now package maintainers are confused on how to handle the keywords. I'd suggest something along the line "arch team can use stable keywords to their own purposes for @system and closely related packages, e.g. to facilitate stage building, but package maintainers may ignore the stable/nonstable status of a package on these arches when bumping and dropping. Default profile settings remain "~arch arch". http://thread.gmane.org/gmane.linux.gentoo.devel/89844 ^ Documenting the profile types is a very good idea. It's true that it should also go in the devmanual though. Mike is right (comment 11) that following these definitions the "minor arches" should be "exp" instead of "dev", otherwise dropping the keywords is again not really possible. [Which makes me think whether the "exp", "dev", "stable" classification really catches all useful cases, I'd like to have something like "nonstable" which is "stable repoman behaviour without checking stable keywords" and "dev-nonstable" which is "dev repoman behaviour without checking stable keywords". Why not make it possible to keep an ~arch only deptree consistent. But that's another discussion and can be done later.]
Bug 488708, RESOLVED, FIXED, without m68k/s390/sh, because bugzilla is now listing these only as 'unstable' in the CC list The bug closing was followed up by ebuild clean up (old) This caused virtual/libusb to have stable m68k/s390/sh, but since bug 488708 was never done, the providers were left at ~m68k/~s390/~sh So, correct action was to revert the virtual also to ~arch, to match providers Is that how this is supposed to work, that the arch's will catch up silently without adding them to CC list of bugzilla for an STABLEREQ? If not, start by fixing bugzilla to now list them as 'unstable' if they are not
(In reply to Samuli Suominen from comment #21) > If not, start by fixing bugzilla to now list them as 'unstable' if they are > not *now -> not Typing error. Sorry.
(In reply to Samuli Suominen from comment #21) > Is that how this is supposed to work, that the arch's will catch up silently > without adding them to CC list of bugzilla for an STABLEREQ? Yes. Wasn't my idea.
I'm marking this one as RESOLVED/FIXED, per today's Council meeting. If somebody feels there is still something left to discuss, please let us know.
