public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Alec Warner <antarus@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Last rites: app-text/cuneiform
Date: Mon, 25 Mar 2013 00:46:50 -0700	[thread overview]
Message-ID: <CAAr7Pr8WbpVS0jmCmPo=1D5Btk==FopBvrKEENQwhQmEyr-8Mw@mail.gmail.com> (raw)
In-Reply-To: <CAGfcS_mFT1HfBNKPOGJR=7rP9ZwYGaSXz5=7Gu-xUJxhD8A9Lg@mail.gmail.com>

On Sun, Mar 24, 2013 at 4:40 PM, Rich Freeman <rich0@gentoo.org> wrote:
> On Sun, Mar 24, 2013 at 3:24 PM, Ian Stakenvicius <axs@gentoo.org> wrote:
>> The number of open bugs doesn't really matter, it's what those bugs
>> are that matters -- security bugs, sure, are of a higher priority and
>> can be fairly easily detected in bugzilla.
>
> Well, our current treecleaner policy seems to be that if a package
> isn't maintained and has any bugs open at all it is fair game.  The
> caveat to that is that trivial bugs are grounds for fixing instead of
> removals (bad DEPEND atoms, simple-to-fix, etc).  Google the full
> policy for details.

So Treecleaners exists to do two jobs.

1) Keep the number of packages in the tree from growing out of
control. It is easier to add software to the tree than to remove it.
There is no policy for adding software to the tree (in terms of
minimum # of users, etc.) There is a policy for removal. Prior to the
policy being adopted, I would remove packages without notice (or
often, without masking.) This angered people, which is why the policy
was adopted; to inform users why a package was being removed, and what
they could do about it. This is why the masks exist at all.

2) Remove dead packages. This is perhaps the more hotly debated
section. My intention was not to remove packages that compiled and
worked, but had bugs. I think your statement about buggy packages is
apt. In many cases the target of TreeCleaners was portions of the tree
that were basically under-maintained and dead. This consisted of
software that did not build, or built, but did not run. Generally
security bugs were already taken by security@ (in 2007 anyway.)

Sometimes users are using dead packages. One of the reasons why
proxy-maint was established was to get interested users to step up and
maintain the packages they wanted; in the beginning I wanted
TreeCleaners to be 'maintainer-needed' and fix up all the broken
packages. Sadly though, there are too many broken packages for such a
small team.

-A

>
> I think that a better policy would be rather than having any open
> non-trivial bugs we list the sorts of bugs that should be grounds for
> removal, such as:
>
> 1.  Package does not build in the majority of cases on all archs.
> (Unkeywording is the solution for individual archs that are broken, if
> not easily fixable.  Not building some of the time isn't grounds for
> removal.)
>
> 2.  Package has an open security bug.  (Cuneiform is a borderline case
> of this - no exploit/CVE but I wouldn't use it on a server being fed
> images submitted by strangers.)
>
> 3.  Package is blocking another package.  Maintained packages always
> take priority over unmaintained ones.
>
> Perhaps there are other cases which should be included, but I think
> this covers most of them.  If a package isn't blocking anything else,
> doesn't have security problems, and works most of the time, then I
> think it should generally be kept.
>
> Rich
>


  parent reply	other threads:[~2013-03-25  7:46 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-22 23:03 [gentoo-dev] Last rites: app-text/cuneiform Markos Chandras
2013-03-23 19:52 ` James Cloos
2013-03-23 20:06   ` Markos Chandras
2013-03-23 20:13     ` James Cloos
2013-03-23 20:21       ` Markos Chandras
2013-03-23 20:29       ` Rich Freeman
2013-03-23 21:40         ` James Cloos
2013-03-24  9:45           ` Rich Freeman
2013-03-24 13:02           ` Sergei Trofimovich
2013-03-23 21:33       ` Alec Warner
2013-03-24 13:24         ` Peter Stuge
2013-03-24 13:38           ` Rich Freeman
2013-03-24 13:52             ` Peter Stuge
2013-03-24 14:12               ` Rich Freeman
2013-03-24 14:35                 ` Peter Stuge
2013-03-24 14:54               ` Markos Chandras
2013-03-24 15:19                 ` Peter Stuge
2013-03-24 19:24                   ` Ian Stakenvicius
2013-03-24 23:40                     ` Rich Freeman
2013-03-25  7:05                       ` Róbert Čerňanský
2013-03-25  7:46                       ` Alec Warner [this message]
2013-03-24  9:15       ` Róbert Čerňanský
2013-03-24 10:43         ` Markos Chandras
2013-03-24 11:22           ` Rich Freeman
2013-03-24 12:11             ` Markos Chandras
2013-03-24 12:18               ` Rich Freeman
2013-03-24 12:31                 ` Markos Chandras
2013-03-24 12:40                   ` Rich Freeman
2013-03-24 14:48                     ` Markos Chandras
2013-03-25 10:22                       ` Ben de Groot
2013-03-24 19:00                     ` Róbert Čerňanský
2013-03-24 13:40               ` Peter Stuge
2013-03-24 13:48                 ` Rich Freeman
2013-03-24 14:14                 ` Alan McKinnon
2013-03-24 14:51                   ` Peter Stuge
2013-03-25  0:23                 ` Patrick Lauer
2013-03-25  0:26                   ` Rich Freeman
2013-03-25  3:17                     ` [gentoo-dev] " Duncan
2013-03-25  7:08                   ` [gentoo-dev] " Róbert Čerňanský
2013-03-25  6:25         ` Sergey Popov

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='CAAr7Pr8WbpVS0jmCmPo=1D5Btk==FopBvrKEENQwhQmEyr-8Mw@mail.gmail.com' \
    --to=antarus@gentoo.org \
    --cc=gentoo-dev@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