Tom Wijsman wrote: > "Steven J. Long" wrote: > > > Closing those bugs as WONTFIX is more work, and in some cases the bugs > > would be justified, if the user is on the slow arch in question. > > They are less work; since it lets the slower arches move their work to > bugs of important packages that need their attention, instead of bugs > of non-important packages were the stabilization isn't really necessary.
Huh? The slower arch is not keeping up with stabilisation. How can the stabilisation suddenly be unnecessary? If it is not needed, there is no problem, and we wouldn't be having this discussion. Much better for the arch in question to field the bug, than tell the user there is no problem, and we don't care. That way you can get the user involved in stabilisation and AT via that bug, instead of turning them away with priggishness. No wonder you're short of manpower. > > The arguments and headaches at the user, bug > > and AT sides are causing more work (or detracting from real work) too. > > Yes, the less work that we can do, the more work the user has to do as > a natural consequence; discussions like these are there to prevent > those headaches way in advance, as we can proper adapt and/or respond > to the situation. And if needed, bring out news such that the user is > well informed. Not sure which argumentation this is about though. Perfectly simple: instead of having this row repeatedly, or borking archs, let's use the solution proposed by the ARM AT: provide a technical reason why it won't work, rather than a conceptual problem with the "hack". The history of computing is littered with hacks that turned out to shed new light on a problem: it's called exploring the problem domain. It's only when you have idiomatic knowledge of the language/tools *and* the specific domain, that you can envision oddball solutions and more importantly _know_ that they will work (perhaps with a bit of tweaking.) <snip> > [1] Quality Assurance / Policies / Dropping Stable KEYWORDs > > https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies#Dropping_Stable_KEYWORDs That's not a policy: it's a two-line statement of intent. Further, the solution steev brought up is much much better than simply dropping the ebuild. > > Just keep the old ebuilds as useful metadata, subject to the usual > > version-control cycle, but iff it's causing you problems and you want > > to drop it, mark it with: "-* slowe rarch" so we can script off it and > > automate bug-handling etc. so your life is easier, as well as the > > archs in question (and their users.) > > As stated before, -* means something way different; it is a suggestion > that does not fit this thread. Like before, did you mean "slower arch"? No, it's an example, like foo bar, but indicating that we're talking about slower archs, and likely more than one in some instances. As before did you mean to raise a technical objection with clear explanation of what and why it would break? > And even if you did, we have then already been using this practice for > a long while; it is different from the problem that was brought up here. Yes, yes, you can keep going on about the "conceptual difficulty", but the simple fact is the solution works, or it wouldn't have been raised. steev's idiomatic knowledge and solution wins, IMNSHO. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
