Re: [Ksummit-2008-discuss] Fixing the Kernel Janitors project

On Thursday, 29 of May 2008, James Bottomley wrote:
On Thu, 2008-05-29 at 17:06 +0200, Jiri Kosina wrote:
On Thu, 29 May 2008, James Bottomley wrote:

Really, I think that's what our mistake is in the recruitment program
is: we need to start people out on useful tasks that they can do rather
than on tasks we find annoying and useless in the hope they move on to
something better.

I fully agree, but my impression is that this really is not going to be
easy. Fixing bugs definitely is a good way to start kernel coding -- it
forces you to understand the internals of the source, get used to the
coding style by reading the code, etc. Unfortunately, it's simply not very
attractive for newcomers.

Yes, that's why I think they don't start with bug fixing, they start
with testing (which, of course naturally leads to bug reporting and
possibly even fixing).

For example -- I am leading a seminar at university, oriented at linux
kernel internals. I provide the possibility to students either to

- write some stand-alone interesting kernel project
- fix a few non-trivial bugs in kernel bugzilla
- chose any part of a kernel, learn how it works, and present this to
other seminar attendees

The feedback I often get from students (and these guys are studying
computer science) is

- writing some wholy new interesting kernel project is usually too
complicated (both coming with an interesting idea for a project, and
doing the coding itself)
- fixing random bugs from kernel bugzilla is boring (spending 10 hours
looking for missing '=' doesn't really attract them)

So in overwhelming majority of cases, they just chose the presentation.


All I want to say is that I could very well imagine that a lot of
newcomers will find "hey, feel free to crawl through bugzilla and fix
whatever you are able to fix" very non-attractive.

Right ... for me to fix a bug, it really has to be relevant, which
finding some random one in the bugzilla isn't, so the most motivated
person on a bug should be the reporter.

Agreed.

That's why I think we start newbies off with testing the kernel of the day
and seeing what goes wrong. If something does, they have the bug right there
in front of them. Just reporting it and helping others fix it is a useful service.
If they actually move on to investigating and fixing it themselves, so
much the better.

Agreed again.

Generally, I think a good way to start is to ask yourself if there are any
problems with the kernel that you see on your own box and you'd like to fix,
then try to understand why these problems occur and try to provide a solution.

Not that I have any better idea right now, though.

Well, apart from bug fixing and testing, I don't either ... that's why
I'm proposing a discussion not a solution.

Well, people usually have some problems with the kernel, not necessarily bugs,
but things that are somehow annoying or apparently possible to improve (eg. to
speed up). Sometimes the kernel doesn't work as expected, etc. IMO, it would
be nice if people started from looking at things that don't work for them
ideally.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • please pull from the trivial tree
    ... Fix spelling in E1000_DISABLE_PACKET_SPLIT Kconfig description ... +- Finding patch that caused a bug ... +Always try the latest kernel from kernel.org and build from source. ... Length of input string in bytes ...
    (Linux-Kernel)
  • Re: ext3 mount infinite loop over orphan list issue, please release 2.6.27
    ... I have put your suggestion about the Rescue CD & patch to kernel to the Ubuntu forums & bug. ... kernel (rc1 has the fix), ...
    (Linux-Kernel)
  • RE: [Full-Disclosure] Re: Full Disclosure != Exploit Release
    ... > wasn't important to fix. ... specific bug. ... and they wouldn't be fixing it as they are concentrating on supporting 32bit ... The information contained in this email and any attachments is ...
    (Full-Disclosure)
  • Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices
    ... I am able to decide myself what is a bug and what ... Looks like a typical answer from somebody who's thoughts are limited to a Linux ... >there's a Linux kernel bug, people should be pointed at linux-kernel and ... As it takes only 5 minutes to fix the include ...
    (Linux-Kernel)
  • Re: RFD: Kernel release numbering
    ... To many (mostly kernel developers) ... Bug tracking could help, but it would have to be universal ... > branches is a fundamentally flawed process that is sure to allow some bug fixes ... Maybe even the one who reported the problem can fix it. ...
    (Linux-Kernel)