Messages in this thread | | | Subject | Re: [Ksummit-2008-discuss] Fixing the Kernel Janitors project | From | James Bottomley <> | Date | Wed, 28 May 2008 16:01:57 -0500 |
| |
On Wed, 2008-05-28 at 23:49 +0300, David Woodhouse wrote: > On Wed, 2008-05-28 at 12:20 -0500, James Bottomley wrote: > > In the early days, the project was conceived as a way of getting fresh > > blood into kernel development by giving them fairly simple but generally > > useful tasks and hoping they'd move more into the mainstream. If we > > wind forwards to 2008, there's considerable and rising friction being > > generated by janitorial patches. This is only an example: > > > > http://marc.info/?l=linux-kernel&m=121135889328760 > > > > but there are many more. > > The example that sums it up for me is this one: > > http://lkml.org/lkml/2008/5/18/20 > > We have people making minor cosmetic changes, and not paying even the > _slightest_ attention to what they're doing. This one's a particularly > scary example because it's something even the most non-technical person > should have spotted; there's _no_ excuse. It's the cosmetic equivalent > of a naïve warning fix that leaves the actual bug in place. > > I think you're right that the status quo is damaging, and I don't see it > getting any better with the current quality of 'janitoring'. I think the > only way we can salvage anything useful from the janitors project is to > keep a close rein on what tasks are actually undertaken. > > But we've pushed back on people doing this kind of thing before, and > pointed them both at the obvious things they've missed in the context of > their patches, and other more useful things they could be doing -- but > we've often received responses along the lines of "but I don't want to > have to _think_!". > > It's hard to know where to go from there, and it's not exactly > surprising that we end up frustrated.
Right, but that's why I think we have to change the process. If we keep the Janitors project, then the bar has to be raised so that it becomes more participatory and thought oriented (i.e. eliminate from the outset anyone who is not going to graduate from mechanical changes to more useful ones). That's why I think bug finding and reporting is a better thing to do. There are mechanical aspects to finding bugs but it is a useful service. Bug fixing is participatory because we usually do quite a lot of back and forth between the reporter and the fixer and at the end of the day quite a few people get curious about how the bug was triggered in the first place and actually go off and read the code.
James
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |