Important kernel update should not break stuff

[Roman Kennke]

Am Mittwoch, den 13.06.2012, 14:29 +0200 schrieb Stijn Hoop:
> Hi,
> 
> On Wed, 13 Jun 2012 14:15:14 +0200
> Roman Kennke <rkennke at redhat.com> wrote:
> > Am Mittwoch, den 13.06.2012, 13:05 +0100 schrieb Johannes Lips:
> > > I think the reason for shipping the latest upstream kernel is based
> > > on the fact that backporting would be too much work.
> > > http://fedoraproject.org/wiki/KernelRebases
> > > Gives a good overview and probably prevents us from repeating
> > > arguments in the discussion.
> > 
> > Ok, fair enough. The question remains, how can we avoid such bad
> > things to happen in the future? Should I regularily try out kernel
> > builds on their way to stable, and object to their stable-release
> > when I find a problem? And how would I do that? (I.e. how can I find
> > out when a new kernel is about to go to stable, and when to test it,
> > etc) And what about the other base components of the system?
> > (Although, to be fair, the kernel seems to be the most problematic
> > one..)
> 
> Check
> 
> https://admin.fedoraproject.org/updates/kernel
> 
> for updates. Provide negative karma for them in Bodhi as well:
> 
> http://fedoraproject.org/wiki/QA/Updates_Testing

Thanks everybody!

I subscribed to the above updates/kernel RSS feed and will try to test
kernels before they go to stable.

Would it make sense to require more karma than just the default 3?
Looking at:

https://admin.fedoraproject.org/updates/FEDORA-2012-8824/kernel-3.4.0-1.fc17

I see that there are 5 oks and 2 denys, which actually point to bug
reports, both sound fairly important. How does the karma system work if,
e.g., update requires +3, the update gets +4 and -1, and this -1 is
something that can be considered a release critical bug? data corruption
sounds quite release-critical? Is there a mechanism that prevents the
update to happen in this case?

Roman