Important kernel update should not break stuff

Roman Kennke rkennke at
Wed Jun 13 20:37:57 UTC 2012

Am Mittwoch, den 13.06.2012, 12:07 -0700 schrieb Adam Williamson:
> On Wed, 2012-06-13 at 09:36 -0400, Josh Boyer wrote:
> > On Wed, Jun 13, 2012 at 9:24 AM, Roman Kennke <rkennke at> wrote:
> > > 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?
> > 
> > Good questions.
> > 
> > The person that submits the update gets emails for every comment added
> > to the update.  This particular one had a couple things that happened
> > though.
> > 
> > 1) It got the requisite karma for stable rather quickly
> > 2) Justin was on vacation when the negative karma was submitted.  Bodhi
> > only emails the update submitter and the rest of the kernel team didn't
> > notice.
> > 
> > I'm sure that it would have been pulled if Justin was actually around
> > or if the rest of the kernel team had remembered to go check the
> > update.  It's something that can be looked at in the future.
> This can also serve as my quarterly reminder that Bodhi 2.0 is _still_
> supposed to be coming, with much better feedback features. The simple
> +/- points system in Bodhi 1.0 isn't really adequate for any number of
> scenarios, including this one. I have posted before about what benefits
> a better feedback system would have:

What you lay out there sounds useful indeed! I hope it's coming.

One thing that might be useful to think about is the way Debian handles
transitions. (Forgive me if the following is not 100% correct, I am only
remotely familiar with what I am saying.) Packages in testing (or
unstable) can only transition to the next more stable repository if
certain conditions are fulfilled. One is to be the at least X days,
another is to not have any (new) release critical bugs in it. (I think
there are more, but those two seem important.) In order to accomplish
this, the package update system (I guess it would be comparable to
Fedora's Bodhi) is linked to the bug DB, and bugs for a package can have
a severity of 'release critical' which basically blocks transitions of
the package. I think something similar could be useful for Fedora as
well, i.e. link Bodhi to bugzilla and react on certain things like
severity of bugs.

Of course, it still means that somebody actually needs to test it in
order to find and file bugs...


More information about the devel mailing list