1 |
On Sat, Mar 23, 2019 at 2:26 PM Rich Freeman <rich0@g.o> wrote: |
2 |
|
3 |
> On Sat, Mar 23, 2019 at 10:17 AM Alec Warner <antarus@g.o> wrote: |
4 |
> > |
5 |
> > |
6 |
> > Avoid letting the perfect be the enemy of the good here. |
7 |
> |
8 |
> Indeed, we need to avoid treating packages as unmaintained simply |
9 |
> because they have open bugs. |
10 |
> |
11 |
> Many packages have bugs that are fairly trivial in nature, or build |
12 |
> issues that only show up in fairly obscure configurations. These |
13 |
> often affect only a single user. |
14 |
> |
15 |
|
16 |
So this is why I advocate for building a number of signals, and using a |
17 |
combination of signals to determine if a package is unmaintained. |
18 |
|
19 |
|
20 |
> |
21 |
> If we treeclean the package we don't actually fix the problem - we |
22 |
> just drive it to an overlay. Now instead of a package that works for |
23 |
> 11/12 users and has an obscure but, we now have a package that isn't |
24 |
> getting monitored for security issues, and other QA issues that might |
25 |
> actually be fixed if they were pointed out. |
26 |
> |
27 |
> > Rules: |
28 |
> > A package is unmaintained if it: |
29 |
> > - Has not been touched in 5 years |
30 |
> |
31 |
> Do we really want to bump packages just for the sake of saying that |
32 |
> they've been touched? That seems a bit much. |
33 |
> |
34 |
|
35 |
I'm not saying "we should absolutely remove packages that have not been |
36 |
touched in N years" but I am saying "we should review packages that have |
37 |
not been touched in N years". |
38 |
|
39 |
|
40 |
> |
41 |
> > - Is behind 3 versions AND hasn't been touched in 2 years |
42 |
> |
43 |
> If we have the ability to detect if a package is behind upstream, |
44 |
> perhaps we should actually file bugs about this so that the maintainer |
45 |
> is aware. |
46 |
> |
47 |
> However, the fact that a newer version exists doesn't necessarily mean |
48 |
> that there is a problem with the older version. For some types of |
49 |
> software a maintainer might be picky about what updates they accept. |
50 |
> For example, they might need to synchronize versions with other |
51 |
> distros that update less often/etc. They should of course accept |
52 |
> contributions from others willing to test, but the fact that somebody |
53 |
> is maintaining a package on Gentoo doesn't obligate them to always |
54 |
> support the latest version of that package. |
55 |
> |
56 |
|
57 |
> Now, obviously if there is a security issue/etc then we should follow |
58 |
> the existing security policies, but those are already established. |
59 |
> |
60 |
|
61 |
Would you be happier if there was some kind of opt-out or whitelist? |
62 |
|
63 |
Have you looked at mgorny's recent removals? its mostly stuff that doesn't |
64 |
build and hasn't been touched in 5 years and *yeah* I want that stuff out |
65 |
of the tree; its a net negative for everyone. Keeping packages in the tree |
66 |
isn't free. |
67 |
|
68 |
|
69 |
> |
70 |
> -- |
71 |
> Rich |
72 |
> |
73 |
> |