Adam Williamson wrote:
> Yeah, it's not perfect: there are cases where we have, say, a complex
> kernel update which works fine for most people but causes a significant
> regression for some particular bit of hardware. We wouldn't want to put
> that update out, but it's easy for it to get five +1s before someone
> with the specific bit of hardware comes by and gives it a -1...and even
> then, +4 looks good if you're not reading the feedback too carefully.
The big problem is of course when the update fixes some really bad issues
for some hardware and causes other really bad issues for some different
hardware. Sadly, that's quite common with kernel updates, and a tradeoff has
to be made. But that tradeoff usually isn't quantifiable by a karma number.
IMHO it should always be the maintainer's call when to push updates (well,
actually IMHO a provenpackager should be allowed to hit "push to stable" as
well, we've had a few cases of updates required to fix some KDE issue which
the maintainer queued to testing and let sit there for ages; provenpackagers
can already queue new updates to stable, so why can't they promote existing
ones?), the karma system is just useless.
Kevin Kofler
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
