1 |
On Thu, Jan 5, 2017 at 8:27 PM, Kent Fredric <kentnl@g.o> wrote: |
2 |
|
3 |
> On Tue, 3 Jan 2017 10:23:02 -0500 |
4 |
> Rich Freeman <rich0@g.o> wrote: |
5 |
> |
6 |
> > I tend to be firmly in the camp that a package shouldn't be removed |
7 |
> > unless there is evidence of a serious bug (and that includes things |
8 |
> > blocking other Gentoo packages). |
9 |
> |
10 |
> I would probably go further and extend that argument to older versions |
11 |
> of packages, for similar reasons, at least in regards to older versions |
12 |
> with specific and exclusive APIs. |
13 |
> |
14 |
> |
15 |
So my understanding of the status quo is that maintainers get to make the |
16 |
call with regard to what is reasonable to keep or drop. I'm loathe to add |
17 |
additional policy here; mostly because the expectation is that the |
18 |
maintainer has the most state here. That doesn't mean you can't: |
19 |
|
20 |
1) Try to convince the maintainer that older versions are needed to support |
21 |
some important use case. |
22 |
2) Volunteer to help in maintenance of older versions to support your |
23 |
important use case. |
24 |
|
25 |
I'm unclear on how having a more explicit policy is advantageous. |
26 |
|
27 |
|
28 |
> Our duty as maintainers is to protect our users from the mistakes |
29 |
> upstream make as much as possible, not to protect ourselves as |
30 |
> maintainers from having difficult challenges. |
31 |
> |
32 |
But our duty here doesn't extend to protecting users from problems the |
33 |
> user knows don't affect them. |
34 |
> |
35 |
> If for example, a media playback suite has a memory corruption bug when |
36 |
> playing media of a certain type, making it unusable when playing that |
37 |
> media, it does seem reasonable for us at first to kill that suite. |
38 |
> |
39 |
> However, if the user in question knows they're never going to play |
40 |
> that certain type of media, and only uses that media suite for a narrow |
41 |
> and specific kind of problem, then we're not serving them much utility, |
42 |
> or much freedom of choice by ripping this tool out of their hands for a |
43 |
> problem they'll never have. |
44 |
> |
45 |
> Maybe we need an intermediate option, where the sensible default when |
46 |
> we discover this kind of error is to remove it, but provide a way to |
47 |
> easily restore that package if the users are ok with it. |
48 |
> |
49 |
> Like, this is not my proposal, just an idea so you can see where I'm |
50 |
> headed with thoughts: |
51 |
> |
52 |
> If packages had a field called "BUGS=" it could contain an array of |
53 |
> bugs a package is known to contain, but can be conditionally avoided if |
54 |
> you're careful. |
55 |
> |
56 |
> Packages with non-empty BUGS= fields would be treated as hard-masked |
57 |
> for the purpose of repoman checks, and so packages that depend on |
58 |
> specific version ranges of packages with BUGS= fields are invalid, |
59 |
> and need their own BUGS= fields. |
60 |
> |
61 |
> Users get portage by default telling them "X package has to go away, |
62 |
> because it has bug #145 , #1286234, and #123756" |
63 |
> |
64 |
> And if this is not satisfactory, they can override portage with |
65 |
> |
66 |
> ACCEPT_BUGS="145 1286234 123756" |
67 |
> |
68 |
> You could even have |
69 |
> |
70 |
> BUGS=" x86? ( 112345 )" |
71 |
> |
72 |
> This to me sounds like a more user-empowering approach. |
73 |
> |
74 |
|
75 |
Treecleaning to me is really two things: |
76 |
|
77 |
1) developer maintenance time. |
78 |
a) It costs nothing to add packages to the tree, and the tree grows in |
79 |
size every year. |
80 |
b) Removals occur due to obsolescence (X replaces Y, etc) but these are |
81 |
strictly less than the addition rate. |
82 |
c) Treecleaning is an attempt to aid in the reducing growth rate of tree |
83 |
size by removing packages. |
84 |
d) The concern here is nominally overall maintenance work (not a technical |
85 |
component like computing resources.) |
86 |
2) A clear indication that this ebuild is unmaintained and may be broken; |
87 |
even if marked stable. |
88 |
a) Nominally we have maintainer-needed or similar tags for packages which |
89 |
indicates this. |
90 |
b) Packages tended to be tested at stabilization time, but never tested |
91 |
again[1] ( sometimes for years.) |
92 |
c) The packages have no maintainer, so have many open bugs, and users |
93 |
shout into the void on bugzilla. This leads to a bad user experience. |
94 |
|
95 |
The nice thing about ::graveyard or similar is that its a clear demarcation |
96 |
between maintained (in tree) and unmaintained (graveyard.) It also means |
97 |
that people doing actual maintenance work can basically ignore the |
98 |
graveyard as a matter of policy. The ebuilds are archived there (for users) |
99 |
but since they are unmaintained they may not work correctly. |
100 |
|
101 |
[1] Tinderboxing can help here, specifically if upstream provides a test |
102 |
suite so we know the package builds and does some correct things. |
103 |
|
104 |
|
105 |
The only questions to me are: |
106 |
> |
107 |
> - Do we have the resources to support this kind of strategy? |
108 |
> - How much additional complexity and confusion will this introduce for |
109 |
> users? |
110 |
> - Is that additional complexity and confusion something users want to |
111 |
> indulge, or is our current feature set already too complex. |
112 |
> |
113 |
|
114 |
> That last one is pretty much the one that weighs most on my mind |
115 |
> lately, with users frequently stumped by handling subslot upgrades |
116 |
> and required-use conflicts. |
117 |
> |
118 |
> Granted, this is just yet-another alternative flavour of hard-masking |
119 |
> things, so I'd rather we stick with careful use of hardmasks to inform |
120 |
> users of problems they might face, allowing them to contravene the hard |
121 |
> masks if they're feeling like they want to be adults. |