On 05/26/2015 06:22 PM, Stephen Gallagher wrote:
On Tue, 2015-05-26 at 15:33 +0200, Ralf Corsepius wrote:
On 05/26/2015 12:10 PM, Andrew Haley wrote:
Something needs to be done, but I'm not sure
exactly what.
IMO, all this should not be a problem, if collaborative maintenance
works.
What I mean, IMO, critical packages should have a sufficient number
of
co-maintainers, who should be presumed to be sufficiently familiar
with
a package to provide enough karma, which would allow such packages to
pass quickly.
That might work for comparatively simple packages, but what about the
kernel? Kernel updates have the potential to completely break things
(particularly if the security patch comes along with a point release).
Well, admitted the kernel is a special case :-)
Therefore, I wrote "co-maintainers, who should be sufficiently familiar
with a package" above, and did not write "arbitrary packagers" or
"arbitrary users". I am presuming "knowledgeable people", who at least
are able to estimate the impact of a set of changes in cases of "urgent
security updates".
IMO, arbitrary users' karma are mostly worthless - in general. In most
cases, all these karma-votes are telling is "update doesn't immediately
let my system go up in flames".
I'm not trying to disparage the kernel maintainers, but there's
absolutely no way they can test all possible hardware before releasing
an update.
There's still value to the updates-testing repo, even for security
updates.
Definitely. May-be I wasn't clear enough. I do not want to circumvent
updates-testing, but wanted to sketch a route to utilize updates-testing
even for urgent security updates.
I agree we need to figure out ways to "grease the wheels" so that
important updates get out faster, though.
The aspect I was referring to is "urgency". In this cases, IMO, it's
more than appropriate to ask those people who can be assumed to be best
knowledgeable (e.g. co-maintainers and/or a dedicated "security team")
to team up.
Of course, this all presumes "critical" packages (firefox, thunderbird,
kernel, glibc, ssh/ssl etc,) and updates have a team behind and aren't
soloist efforts.
Ralf
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
