From: Rich Freeman <rich0@gentoo.org>
To: gentoo-project@lists.gentoo.org,
Richard Freeman <rich0@gentoo.org>,
Sergey Popov <pinkbyte@gentoo.org>
Subject: Re: [gentoo-project] Council meeting 2015-01-13: call for agenda items
Date: Wed, 7 Jan 2015 12:45:07 -0500 [thread overview]
Message-ID: <CAGfcS_mzh5yeXQm3QhGweeFU0EyFwqqbD6a+iY9OpDt1yY-oVw@mail.gmail.com> (raw)
In-Reply-To: <20150107163052.GA7151@linux1>
On Wed, Jan 7, 2015 at 11:30 AM, William Hubbs <williamh@gentoo.org> wrote:
> That's the whole point of a last rites, to get people to step up and
> take responsibility for packages. Also, this was cleared with the qa
> lead before it was ever sent out.
Define "take responsibility for packages." As far as I'm aware there
is no policy that requires maintainers to fix any upstream bug, and
security issues are almost always upstream bugs.
A package with a security bug for 10 years could be perfectly
well-maintained, with regular updates/etc as often as upstream
publishes them. Some software projects are fairly mature and don't
get a lot of upstream updates, so a package might be untouched for 5
years and have security issues and still be "well-maintained."
I think the solution to this is to have the community agree on just
what "well-maintained" actually means and documenting this as policy,
versus just making individual judgment calls. To be sure there will
still be grey areas, but I think that right now the policies are too
vague to try to enforce something like this.
>
> So I am operating clearly within the scope of qa, since the job of QA is
> to keep the tree in a consistent state for our users.
>
> So with all respect, I don't understand why this even needs to be
> escalated to the council.
There are many who would probably say that the tree is already in a
consistent state for our users. I realize that you feel otherwise,
and perhaps others in QA also feel otherwise. Maybe the vast majority
of the community would agree with you, but the whole reason for this
discussion and putting this on the Council agenda is so that we can
can get a sense for what the community wants and then consistently
follow that as policy.
It makes far more sense to deal with general policy issues like this
before we start treecleaning than to just leave it up to QA, have
users switching to overlays, and then have it appealed to the council
and potentially have everything re-introduced to the main tree.
--
Rich
next prev parent reply other threads:[~2015-01-07 17:45 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-27 12:34 [gentoo-project] Council meeting 2015-01-13: call for agenda items Andreas K. Huettel
2014-12-28 11:43 ` Anthony G. Basile
2014-12-28 11:57 ` Michał Górny
2014-12-28 16:45 ` Andreas K. Huettel
2014-12-28 16:54 ` Michał Górny
2014-12-29 0:02 ` Patrick Lauer
2014-12-29 20:57 ` Matthew Thode
2014-12-29 21:44 ` Andreas K. Huettel
2014-12-30 0:18 ` Alex Legler
2014-12-30 14:20 ` Anthony G. Basile
2014-12-30 15:05 ` Rich Freeman
2014-12-30 16:18 ` Anthony G. Basile
2014-12-30 4:59 ` Dean Stephens
2014-12-29 19:34 ` hasufell
2014-12-29 20:06 ` Rich Freeman
2014-12-29 21:02 ` Matthew Thode
2014-12-30 2:22 ` hasufell
2014-12-30 2:47 ` Rich Freeman
2014-12-30 5:00 ` Dean Stephens
2014-12-30 8:28 ` Ciaran McCreesh
2014-12-30 11:31 ` Rich Freeman
2014-12-30 14:25 ` hasufell
2014-12-30 15:12 ` Rich Freeman
2014-12-30 20:51 ` hasufell
2014-12-31 4:19 ` Dean Stephens
2015-01-04 23:27 ` hasufell
2015-01-05 4:38 ` Dean Stephens
2015-01-05 14:06 ` hasufell
2015-01-06 4:25 ` Dean Stephens
2015-01-07 13:03 ` Rich Freeman
2015-01-07 16:30 ` William Hubbs
2015-01-07 17:45 ` Rich Freeman [this message]
2015-01-07 19:35 ` William Hubbs
2015-01-07 21:21 ` Andrew Savchenko
2015-01-08 15:05 ` William Hubbs
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=CAGfcS_mzh5yeXQm3QhGweeFU0EyFwqqbD6a+iY9OpDt1yY-oVw@mail.gmail.com \
--to=rich0@gentoo.org \
--cc=gentoo-project@lists.gentoo.org \
--cc=pinkbyte@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