On Wed, 2014-01-15 at 13:07 -0600, William Hubbs wrote: > When you say "drop keywords" do you mean: > > 1) revert the old version back to ~arch or > 2) remove the old version. > > As a maintainer, I would rather do 2, because I do not want to backport > fixes to the old version. > > William >
I'm not sure what he meant by drop keywords either, however, something that I would like to see (with my ARM hat on here) - is, if something is taking a while to stable for a certain arch, remove the keywords except for that existing arch. We actually ran into something along this issue with git. Now, arm is an interesting keyword, because for arm, when something needs to be stabled, we have to test armv4, armv5, armv6, armv6 hardfloat, armv7, armv7 hardfloat, armv7 uclibc. In my testing, one known issue was that git on uclibc did (and still doesn't) work properly starting with git 1.8 - so I noted in the bug that this was the case, and to NOT stable it for arm. Unfortunately, someone else on the ARM team disregarded the note and stabled the new git, then the git maintainers dropped the old versions. Now on arm uclibc, git is entirely broken and unusable. And no, adding more people to the arch team doesn't particularly help, as people are buying more and more armv7 so they test that, but not the rest of the versions - and no one wants to buy the older hardware "because it's so slow" - we know it's slow, that's why it takes time. I'd have definitely preferred that for git, that the 1.7 version stuck around with just KEYWORDS="-* arm" (and maybe even stabling 1.8 but leaving 1.7 in masked?) - I realize it was a bit of a special case because of the new git eclass. Unfortunately, debugging what's going on, is a bit above me, and the only other person I know who can/does work on it, is blueness, and he's quite busy.
