Important kernel update should not break stuff

Roman Kennke rkennke at
Wed Jun 13 13:24:33 UTC 2012

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> 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.
> > >
> > > 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
> for updates. Provide negative karma for them in Bodhi as well:

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:

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?


More information about the devel mailing list