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(a)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