From: Alec Warner <antarus@gentoo.org>
To: gentoo-project <gentoo-project@lists.gentoo.org>
Subject: Re: [gentoo-project] How to improve detection of unmaintained packages?
Date: Sat, 23 Mar 2019 15:22:07 -0400 [thread overview]
Message-ID: <CAAr7Pr_5y5By2c6zD-dS1u-SkrmJUfgkEfj72iH+q=HVipvoHA@mail.gmail.com> (raw)
In-Reply-To: <CAGfcS_=zTHQNbEXHP=jhgBOFeQgNxMTJeW11TjMEDZr=MOftBg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2587 bytes --]
On Sat, Mar 23, 2019 at 2:26 PM Rich Freeman <rich0@gentoo.org> wrote:
> On Sat, Mar 23, 2019 at 10:17 AM Alec Warner <antarus@gentoo.org> wrote:
> >
> >
> > Avoid letting the perfect be the enemy of the good here.
>
> Indeed, we need to avoid treating packages as unmaintained simply
> because they have open bugs.
>
> Many packages have bugs that are fairly trivial in nature, or build
> issues that only show up in fairly obscure configurations. These
> often affect only a single user.
>
So this is why I advocate for building a number of signals, and using a
combination of signals to determine if a package is unmaintained.
>
> If we treeclean the package we don't actually fix the problem - we
> just drive it to an overlay. Now instead of a package that works for
> 11/12 users and has an obscure but, we now have a package that isn't
> getting monitored for security issues, and other QA issues that might
> actually be fixed if they were pointed out.
>
> > Rules:
> > A package is unmaintained if it:
> > - Has not been touched in 5 years
>
> Do we really want to bump packages just for the sake of saying that
> they've been touched? That seems a bit much.
>
I'm not saying "we should absolutely remove packages that have not been
touched in N years" but I am saying "we should review packages that have
not been touched in N years".
>
> > - Is behind 3 versions AND hasn't been touched in 2 years
>
> If we have the ability to detect if a package is behind upstream,
> perhaps we should actually file bugs about this so that the maintainer
> is aware.
>
> However, the fact that a newer version exists doesn't necessarily mean
> that there is a problem with the older version. For some types of
> software a maintainer might be picky about what updates they accept.
> For example, they might need to synchronize versions with other
> distros that update less often/etc. They should of course accept
> contributions from others willing to test, but the fact that somebody
> is maintaining a package on Gentoo doesn't obligate them to always
> support the latest version of that package.
>
> Now, obviously if there is a security issue/etc then we should follow
> the existing security policies, but those are already established.
>
Would you be happier if there was some kind of opt-out or whitelist?
Have you looked at mgorny's recent removals? its mostly stuff that doesn't
build and hasn't been touched in 5 years and *yeah* I want that stuff out
of the tree; its a net negative for everyone. Keeping packages in the tree
isn't free.
>
> --
> Rich
>
>
[-- Attachment #2: Type: text/html, Size: 3850 bytes --]
next prev parent reply other threads:[~2019-03-23 19:22 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-23 7:32 [gentoo-project] How to improve detection of unmaintained packages? Michał Górny
2019-03-23 8:04 ` Joonas Niilola
2019-03-23 8:48 ` Toralf Förster
2019-03-23 8:51 ` Michał Górny
2019-03-23 14:17 ` Alec Warner
2019-03-23 17:05 ` Raymond Jennings
2019-03-23 17:38 ` Michał Górny
2019-03-23 17:53 ` Raymond Jennings
2019-03-23 18:25 ` Rich Freeman
2019-03-23 19:22 ` Alec Warner [this message]
2019-03-23 19:36 ` Rich Freeman
2019-03-23 20:14 ` Raymond Jennings
2019-03-23 20:32 ` Toralf Förster
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAAr7Pr_5y5By2c6zD-dS1u-SkrmJUfgkEfj72iH+q=HVipvoHA@mail.gmail.com' \
--to=antarus@gentoo.org \
--cc=gentoo-project@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox