1 |
Rich Freeman wrote: |
2 |
> Jeroen Roovers wrote: |
3 |
> > "Paweł Hajdan" wrote: |
4 |
> > |
5 |
> >> Why not allow maintainers to drop redundant stable and even ~arch |
6 |
> >> keywords from their packages? |
7 |
> > |
8 |
> > This is standard practice already. |
9 |
> |
10 |
> If there is still pain then maybe we need to re-communicate this, or |
11 |
> clarify. |
12 |
> |
13 |
> To me if a package is in the tree and is outdated, but kept for only |
14 |
> the benefit of a few lagging archs, then maintainers can close bugs as |
15 |
> WONTFIX if they don't pertain to newer versions. If that is the case |
16 |
> then there is no cost to keeping the old packages around. |
17 |
> |
18 |
> The main concern is around maintenance burden. The only way to reduce |
19 |
> maintenance burden is to do less maintenance (I haven't heard any |
20 |
> suggestions that will somehow make bugs go away). If maintainers are |
21 |
> doing more maintenance than they are required to do, then simply |
22 |
> reinforcing existing policy could solve the problem. We just need to |
23 |
> align around expectations. |
24 |
|
25 |
Closing those bugs as WONTFIX is more work, and in some cases the bugs |
26 |
would be justified, if the user is on the slow arch in question. The |
27 |
arguments and headaches at the user, bug and AT sides are causing more |
28 |
work (or detracting from real work) too. |
29 |
|
30 |
I don't think it should be general policy to drop stable keywords; as |
31 |
someone said, the latest stable in the tree /is/ the stable one, and |
32 |
there's no real point in adding work, *unless* the maintainer |
33 |
actually wants to drop the ebuild, but cannot due to the holdup with |
34 |
slower archs. |
35 |
|
36 |
Just keep the old ebuilds as useful metadata, subject to the usual |
37 |
version-control cycle, but iff it's causing you problems and you want |
38 |
to drop it, mark it with: "-* slowe rarch" so we can script off it and |
39 |
automate bug-handling etc. so your life is easier, as well as the |
40 |
archs in question (and their users.) |
41 |
|
42 |
Regards, |
43 |
steveL. |
44 |
-- |
45 |
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-) |