[RFC] Enabling kerneloops in default install

[Amit Kucheria]

(Retaining entire history since its been a while since this was discussed)

On Fri, Sep 19, 2008 at 9:57 PM, Matt Zimmerman <mdz at ubuntu.com> wrote:
> On Mon, Sep 08, 2008 at 01:33:42PM +0100, Matt Zimmerman wrote:
>> On Fri, Sep 05, 2008 at 11:29:03AM +0300, Amit Kucheria wrote:
>> > Instead, I want to propose moving the 'kerneloops' package[1] to the
>> > default install. Kerneloops ships with a gtk/gnome applet that pops up
>> > when it notices an oops message and offers to send the information
>> > upstream.
>> >
>> > Plus
>> > -----
>> > 1. Kerneloops will report bugs directly upstream to
>> > http://submit.kerneloops.org/submitoops.php
>> > 2. This will help upstream get a better handle on the most critical
>> > kernel bugs experienced by Ubuntu users
>> > 3. It will help to dispel the notion that Ubuntu doesn't really help
>> > with identifying kernel bugs by sticking with older kernels only[2]
>>
>> I think the general idea of collaborating more closely with the upstream
>> kernel community by providing testing is a very good one.
>>
>> > Minus
>> > -------
>> > 1. Kerneloops does something that apport is already doing
>> >     - apport sends it to LP, though. And the bug waits there until
>> > someone decides to send it upstream.
>>
>> We aren't actually submitting oops reports to Launchpad using apport yet,
>> but I think we should.  kerneloops could be modified to do this, so that
>> we're sharing the same code for watching for oopses, and it should be
>> possible to write a tool to push these upstream semi-automatically if
>> they're judged to meet appropriate criteria.
>>
>> That would give us the chance to review the reports before they're sent
>> upstream.
>
> I've now modified kerneloops to add support for writing an apport report in
> addition to the standard kerneloops.org submission.  This will allow us to
> participate in the kerneloops.org statistical measurement, and also receive
> semi-automatic bug reports for oopses which occur in an Ubuntu release which
> is still under development.
>
> I spoke to Arjan about the patch, and he indicated he was willing to accept
> it.
>
>>
>> > Risks
>> > -------
>> > 1. This could backfire if the kernel community does not appreciate
>> > receiving bugs from Ubuntu's modified kernels.
>> >      - With the move to 2.6.27 we are (potentially) not going to have
>> > entire subsystems backported. So bugs in the core kernel would still
>> > be valid reports.
>> >      - A majority of our patches are for HW-enablement (new/modified
>> > drivers) and those are the bug reports that might cause problems.
>> >
>> > Comments on this proposal are most welcome.
>>
>> I'm very concerned about risk #1 you've listed.  Would it be possible to get
>> some feedback from upstream maintainers about whether they want these oops
>> reports or not?
>
> Amit discussed this with Arjan at some length at the Linux Plumbers
> Conference, and the conclusion seems to be that he wants a way to identify
> Ubuntu kernels based on the version number, and confirmation that we'll
> address the top issues which come up (and not let them languish), which is
> already our practice.

The Jaunty kernel (2.6.28-2) now has all the version information
required by kerneloops to identify Ubuntu kernels from an oops.

Could we now move kerneloops to 'main' as part of the default install?

Regards,
Amit