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