Tom Wijsman wrote: > "Steven J. Long" wrote: > > What? Without a stable tree, Gentoo is useless afaic. > > It moves us closer to upstream releases, a little more bleeding edge; a > lot of users and developers run that already, it is found to be useful.
What? More vague. As are many of your philosophical statements in later and prior mails, so I'll ignore those. > > I don't think that's what was being proposed, though. The question was > > really the old complaint about slow architectures; the "-* arch" > > solution sounds like the most reasonable definition of "dropping" > > keywords, in the absence of AT communication otherwise. > > Dropping keywords and specifying -* are a world apart of each other. That's why it's in quotes. > The former means that it is not ready for wide stable or testing users, > the latter means that it has been tested to not work at all; > furthermore, we need to explicitly specify which arches in that case. You're missing the point, again. The question was what does "dropping keywords" mean, when the maintainer has stabilised a newer version on the arch/s s/he has available, but feels that slower archs are holding up that process. I'm slightly at a loss as to why it's such a big deal to just leave the old ebuild as-is, given that anyone on a stabled arch should upgrade automatically. But given that the maintainer feels they don't want that old ebuild around, and that the arch in question has not got round to testing the new one, for whatever reason (it's their call, after all, as to how their arch progresses), instead of simply removing that ebuild, or bumping it to unstable (which makes zero sense), just leave it stable on the slow arch/s in question, and remove the others. If you must do anything, which I'm unpersuaded about, but it's your call, as maintainer. This seems like a rarity, but when it's an issue, people get annoyed on either side. The solution proposed by the ARM team, seems like a simple way round, and indicates clearly to anyone perusing the ebuild, that a newer version needs stabling on the "slow" archs. By all means, raise technical objections; just not a philosophical one. Again this is a minor issue afaic, in terms of frequency, need for change, and how difficult it is to solve. Resolve it, and let's get back to the fun stuff instead. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
