In the spirit of having a more process than technical based kernel

summit, I'd like to put the topic of the kernel Janitors project up for

discussion.
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 greatest problem, as I see it is that by

pouring vitriol like this on newbies, we're really damaging our

reputation as a community that welcomes newcomers and strangling our

necessary supply of willing volunteers.  On the other hand, as a

maintainer, when there's people yelling me at about patches not being

included plus a persistent regressions list and about ten bug reports to

track down, the last thing I want to see within a million miles of my

inbox is a white space fixing patch.  The more of these patches we get,

the worse the problem becomes and the shorter and more inflammatory the

responses get. We can't go on like this.
The most obvious solution might be to shut the Janitors project down, or

at least more tightly manage its TODO list (although a lot of what gets

seen as janitorial patches, like whitespace fixes, isn't on the TODO

list in the first place).  However, since the purpose is to get new

people involved with kernel development, perhaps we should repurpose the

project so it actually does this.  My suggestion is that we replace it

with the kernel bugs project.  Kudos for finding bugs, more for finding

better ways of finding bugs, and the most for finding and actually

fixing a bug.  
Perhaps we should simply start the discussion with the premise that we

want to encourage new people to do useful work and draw them into the

development community and see where it leads.
James
--

My attempt in this direction is described at

http://lkml.org/lkml/2008/5/7/258
Although I do not yet know how it will develop it already resulted in 
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
--

James Bottomley wrote:

This particular problem seems fixable. Put something like this in the

janitor faq:
"Don't create patches that are whitespace-fixes, or similiar attempts to

make the kernel adhere to the CodingStyle without actually changing the

working code. The reasons are:

* Any patch disturbs others working on the same file. So change must be

   justified by usefulness above mere pretty formatting.

* The maintainer can run the code through pretty-printing software

   _when it won't disrupt other activity_. Such software will do

   a better cleanup job than you can, and with no human effort at.

Please find something more useful to do than whitespace/style

improvements on existing code."
And if they do this anyway, just reject the patch with a pointer to the

FAQ entry...
Helge Hafting
--

From: James Bottomley <James.Bottomley@HansenPartnership.com>
Not to distract from your points, but I think it's been a huge

mistake to not allow folks to work hard on technical issues

during the summit.
I feel like I'm at the edge of my seat dieing to talk about

some tech topics, but it's all of this process stuff, it makes

me want to disappear into the local cafe during the main

summit with some folks and talk tech.
I think it would even fix the attitude and process issues,

to be able to talk face-to-face about technical issues instead

of always hashing stuff out in email which is the source of

all of the bad behavior.

--

Actually, it was wrong of me to give that impression.  The summit is

also all about technical discussions.  However, one of the observations

made over the last few years was that it's hard to have a technical

discussion that actively involves a majority of people in the room, so

most of the technical stuff goes on either in the mini-summits (for

discussions within maintainer areas) or in the hallway (for discussions

across maintainer areas) or in BoF sessions.
However, if there's a technical topic that would occupy the attention of

more people than can conveniently be accommodated in the hallway track,
That's sort of an extension of the hallway track (especially in
I agree that having people face to face helps draw heat out of email

discussions, certainly.  My observation though (and it may not be

universally held) has been that the majority of the frictions on the

mailing list isn't necessarily coming from the core people who get

summit invites.
James
--

Having been stopped a couple of times last year when trying to bring

some technical subjects for the reason that they were "off topic, KS is

for process" I tend to agree :-)
There are some things that are hard to get through the list, or even

IRC, such as wanting to reorganize some part of the core and wanting to

get "live" input and discussion with most arch maintainers.
In my case it was some rework on some of the page table batching, for

which I finally didn't finish the work as I'm not too happy with what I

came up with, but I'm still somewhat convinced there's something to do

there and I could use a bit of a group beat-up in a room.
There are other areas like that which would benefit from that kind of

hard core tech discussion face to face.
However, on the other hand, KS is only 2 days, which doesn't leave room

for that much stuff. And I don't think splitting into sub-groups or

mini-summits is necessarily the answers. There are some areas where it's

useful to do the tech beatup -with- everybody in the room.
Just my 2 cents... Maybe we need 2 summits, the process one and the tech

one ? :-)
Cheers,

Ben.
--

Here's an idea: the discussion list for the 2008 summit has opened up.

This seems like an ideal time to make suggestions for technical topics

which you think would be appropriate for this gathering.  Failing that,

you leave it up to the program committee to try to guess what's on

everybody's minds, and that seems certain to disappoint a lot of people.
jon

--

We did have some technical topics last year.  So I don't think the KS
I agree that sometimes face-to-face discussions are crucial to

resolving technical issues.  The problem is that we try to nail down

the agenda a 3-4 weeks ahead of time, and realistically if a

particular topic requires certain stakeholders to be invited, we need

to decide that we're going to do that topic at least 8-9 weeks in

advance, maybe more, so those people can make travel plans and/or get

travel approvals.  And there is always the chance the topic will

resolve itself via e-mail.  So the trick is being able to identifying
First of all, if there is interest in holding some topic-area specific

mini-summits on Sunday before the Kernel Summit, we may be able to

scare up some space.  So if there is interest, please let me know.
Secondly, one of the things which has been suggested in the past is

that we move the BOF's into an afternoon session slot, and maybe push

the last session to run until 7pm, perhaps.  That might make it easier

for people to attend BOF's on the spur of the moment --- which might

be useful in some cases where there is only 10 or so people you need

to hash our some issue.
And, of course, we try to schedule plenty of break time so that some

of these discussions can happy in the hallway.
Do any of these possibilities sound particularly attractive or likely

to address your concerns?  If so, which ones do you think we should

try this year, as an experiment?
						- Ted

--

It's a bit hard, as sometimes, the topics will just show up before hand,

or don't necessarily need special invite list when it's purely something
Ok, if something comes to mind I will :-) The only thing at this stage

would possibly be page table walking (ie, some old work I did on

that to generalize the batch interface to all more-than-one-page

operations such as fork, and to get rid of the per-cpu structures, and

that I never fully finished, along with the mmu notifier stuff and

the various needs around that area such as sleeping during some parts

of page table updates etc...).
We might finally be able to put the whole thing on a table and decide

on a nice / clean solution that I'd be happy to help implement then :-)
Among others, I have had a hard time getting enough input from the

various archs as to get to a design that would fit everybody fine.
We don't -have- to spend time on that, it's just an example, but typically

I think a good one of something that would benefit from a face to face
To be honest, I don't know for sure. A bit like David, I'm not even

certain planning for those things is -that- useful and I must admit

I'm not too fan of long days mostly because I end up always getting

there totally jet lagged :-)
But we can definitely try.
Cheers,

Ben.
--

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
I personally don't even like having to choose presentation topics when

I go to conferences.  What is interesting for me to talk about usually

is changing righ up to the day or two before I travel to the event.
And I think the same thing applies here.
You can pick some topic now, and by the time we actually get to the

summit those folks might have hashed everything out already.
We should just all show up and discuss in appropriate groups whatever

is pressing and interesting at the moment.

--

Ted, we are adults and professional kernel hackers.
If you put us in a room together, we know what the heck to talk

about and what is relevant.  So saying we need to plan the topics and

invite the right people, that's pure hogwash, just invite the same

kind of people we've always been inviting and it will be fine.
It's absolutely absurd to put the best kernel hackers in the world all

together in the same place and talk about process for 3 days.
Yes, process is important, but I'd say it deserved 1/3 of the summit

time, but not one minute more.

--

I do assume people we invite are adults.  That being said, *some*

amout of structure is still a good thing.  And as others have pointed

out, sometimes the sharper disagreements are with people who aren't

invited.  If we know we want to try talk about LSM/Apparmor YET AGAIN

(no I'm not advocating this; besides, I thought Linus has already made

it clear that people who depend on path-oriented security are on crack :-),

we might end up inviting some folks that we might not otherwise

include, just to take one example.
So if people want to talk about things that aren't on the agenda, it's

certainly not carried down by Moses from the mountain and cast in
We were about 50-50 last time, roughly.  So let's see if there is

consensus to dial it back this year, based on topics that people

suggest.
						- Ted

--

From: Theodore Tso <tytso@mit.edu>
Today at LinuxTAG, Thomas Gleixner and I tossed around the idea

that (assuming a 3 day event) we do tech stuff on day 1, process

stuff on day 2, and back to tech stuff on day 3.
The idea is that you hash out the initial impressions of your

ideas on day 1, your mind works on the problem in the background

on day 2, and they everyone has the answers on day 3 :-)
Another idea we discussed briefly was some kind of organized run

over the bugzilla entries.  And just to make it interesting we could

award some silly prize to whoever fixed the most interesting or

amusing bug during the bug-run, as voted by the attendees.

--

I thought more about it and came up with an interesting challange for

the top hackers crowd:
Fix NOHZ/CPUIDLE along with suspend/resume on all participants

laptops, which are probably 50+ different models. That'd be an odd

enough mix of wreckaged hardware / BIOS / ACPI.
Should be fun and solve a bunch of hard to grok bugs in the bugzillas

along the way.
Thanks,

	tglx

--

If we have in-kernel video reinit for the major vendors by then, sure.

If not, I suspect the majority of issues we'd hit would just be "My

screen doesn't come back".
--

Matthew Garrett | mjg59@srcf.ucam.org

--

And why wouldn't it be a good idea to spend time on adding the video

reinit right there at the hacking session ?
Thanks,
	tglx

--

You mean adding the right sequence of whacking 200+ non documented chip

registers in the right order with the right values that have to be

subtly different on each revision and each OEM implementation ? :-)
At least for ATI, we do have the necessary infos to do it actually. We

can parse tables in the BIOS, we know how to, we have the format and the

necessary interpreter, it's mostly a matter of doing it (and

re-implementing the interpreter in code that is acceptable to the

kernel, last I looked, the one in X isn't).
For nVidia, it's harder though the "nouveau" folks do have figured how

to run some of the BIOS foo too (same thing, BIOS contains magic

"scripts" that can be interpreted to bootstrap the card).
For others (VIA, XGI, ...) I don't know.
Cheers,

Ben.
--

Because there's only one guy outside nvidia who understands the nvidia

BIOS tables right now, and I suspect he's not on the invite list :) I'm

actually planning on giving the nvidia stuff a go this week.
--

Matthew Garrett | mjg59@srcf.ucam.org

--

Well ... in theory.
In practice, for instance, my laptop had suspend/resume working shortly

after I got it, and the widescreen video too.  Most of the problems were

video related, so I did interact with the upstream intel video driver

people, but by and large it was a set of black magic rules to restore

the video to its prior state (in my case, even the vbe tools didn't work

and I had to manually save and restore the pci config space).
The point, though, is I'd be incredibly surprised if a kernel hacker had

an unfixed suspend resume problem (except possibly one that just

appeared in the latest upgrade).  It's a fairly important feature and

hackers tend to get annoyed by problems like this and hack on them until

they're fixed.
However, persuading us all to go to the fix my suspend/resume session at

the plumbers conf (which follows directly) would probably achieve a

fairly sizeable crossection of unfixed laptops and possibly quite a lot

of bug fixing ...
James
--

that's s2ram -v, right? Can you submit a whitelist entry so it starts

working for other people, too?
--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--

Actually, it's pm-utils, because I'm using fedora.
This, by the way was years ago, beginning with FC6.  In FC7 we got the

driver to the state where vbestate save/restore worked for it and added

it to the hal database.  Today, at FC9, I've just been busy filing a bug

with fedora because the i915 drm now seems to do everything and actively

screws up if vbestate save/restore is used (so all the work I did with

FC7/8 now needs to be undone).
James
--

Fixed in pm-utils upstream, which knows not to do anything with recent

Intel drm. The trick now is to get nvidia and amd to the same level of

functionality, though in principle we know enough to manage at least the

nvidia case.
--

Matthew Garrett | mjg59@srcf.ucam.org

--

Well, we have the same problem in s2ram.
Thanks,

Rafael

--

No, that won't work.  James uses Fedora.
Thanks,

Rafael

--

Ooh, do I hear a supporter for my idea from a few years ago of having

half the time in sessions and half the time in the hallway track?
(I always felt the presentations were more or less useless.  Maybe that

was different last year.)
--

Intel are signing my paycheques ... these opinions are still mine

"Bill, look, we understand that you're interested in selling us this

operating system, but compare it to ours.  We can't possibly take such

a retrograde step."

--

Turn presentations into BOFs ? :-)
Ben
--

That would certainly reduce the slideware.
jejb complained that this was going to turn into an unconference.

I didn't really know what that meant, so I looked around on

Wikipedia.  It doesn't seem like such a bad idea to me, particularly

some of the more unconventional organising techniques, eg:

http://en.wikipedia.org/wiki/Open_Space_Technology
--

Intel are signing my paycheques ... these opinions are still mine

"Bill, look, we understand that you're interested in selling us this

operating system, but compare it to ours.  We can't possibly take such

a retrograde step."

--

I second this idea, a mini "hack-fest" to hash out some of the ideas and

actually try to start to implement them would be very good.
thanks,
greg k-h

--

I'm kind of hoping that this is going to be one of those topics that

resolves itself -- but just in case it isn't, I'd like to discuss it at

the kernel summit:
I'd like to remove all firmware blobs from the kernel source tree.
With the intention of making that less contentious, I've done the

following: 
I've added support to the firmware loader for finding firmware in a

special section of the static kernel, so that using request_firmware()

no longer forces you to use an initrd or udev. You can build _arbitrary_

firmware files into your kernel, if you want to. Whether you're allowed

to distribute the resulting vmlinux or not is still a question you ought

to ask your lawyer.
I'm working on converting drivers over to use request_firmware(), and

shifting their firmware blobs into .ihex files in a firmware/ directory

of the source tree. For each one, I'm giving the option of continuing to

build it in statically, using the above mechanism.
I've implemented a 'make firmware_install' Kbuild target, which takes

all those firmware blobs and installs them somewhere where udev can load

them on request.
By the time the kernel summit comes around, we should have made decent

progress on moving _all_ the firmware blobs to the firmware/ directory.

And at that point I'd like to remove them completely, to a separate git

tree and tarball. Those who really want to build them in to their static

kernel would still be able to, but it wouldn't be the default behaviour.
--

dwmw2
--

Pretty much on line with others: I like most of what you propose

-except- having the firmwares distributed in a separate git tree. I much

prefer having them still in the main kernel, though distro can choose

not to do so more easily if they are in a separate directory.
Ben.
--

This I disagree with.  Leaving it in a single directory makes it easier

for some distros to patch it away to apease their feelings about the

issue.  But for some of use, we like the firmware in our kernels, it

makes it easier to boot for one, and we don't have to deal with

different firmware packages.  So I say leave them in, with the option to

get them elsewhere, like you are doing.
thanks,
greg k-h

--

I very much would like to see a kernel-firmware or something tarbal that contains

a copy of all relevant "freely distributable" firmware, that users can just install

independent of the actual kernel version (and that kbuild would just pick up somehow).

That way we can deal with a lot more firmware without having to pollute the kernel / kernel release process

(after all, the timing is different in terms of releasing) while making it easy

to get the lot of it.
Now.. of course what "freely distributable" means is a huge debate. I don't care ;)

--

Arjan, by definition the firmware has to be tied to the kernel somehow.

THe datastructure and other aspects are often tied directly to

the firmware version loaded.
At first, people said "hey we're going to make the firmware loadable

from userspace, so sorry now you can't load your driver without a

ramdisk, sorry!"  And that royally pissed me off, and directly impacted

my work flow negatively.
Now, for the cases where we do have in-kernel firmware still, people

are suggesting to seperate that out to a seperate tree as well.

Sorry, that's taking things too far.  I've fought, like, forever, to

keep the tg3 driver with it's firmware in-tree.  I refuse to let the

driver get broken like that, it's staying working, and that means

in-tree and linked into the driver.
If debian or whoever else have these concernes and want to rip the

firmware out, it is one hundred percent their problem to patch things

out of the kernel tree they use.
At least from my perspective this looks like a transfer of burdon from

the folks who want to rip the firmware out, to those of us who find

high value in the firmware staying in the tree.
This is really irritating me, because this is one huge case of frickin

Animal Farm.  First a little was taken away, then a little bit more,

and by the end you have something absolutely nobody would have agreed

to from the beginning.

--

Am I missing something here, or is the tg3 firmware contained in

'tg3FwText' and similar non-swappable u32 arrays which haven't changed

_ever_ in our current git history?
--

dwmw2
--

It certainly has changed. Maybe that was before the move to git.

ISTR, Last time I looked at the tg3 firmware, it was on version 1.4 or 1.5.
thanks,

grant

--

agreed that there are cases like this, and I have no personal objection to having
I don't care at all about the argument from that camp.
My aim was more the opposite: be able to get MORE firmware easily used/loaded,

not less. Right now it's a royal pain for users to get all the right pieces of

firmware.... having ONE place to put all that would go a long way of making that

side of things easier.
If you want to argue that that should be in the kernel tarbal itself, you won't

hear me complain. But others will... and for that a 2nd tarbal might well be the answer.

Just we shouldn't need 100 tarbals.

--

I do -- partly because it's not just from the fundamentalist camp,

partly because (after the work I've been doing) it doesn't actually

_hurt_ us to assume that they're right, but mostly because I have a

horrible suspicion that they _are_ right.
Expanding on those three points not in that order...:
The firmware is an independent and separate work in itself. Section 2 of

the GPL talks about such sections of the work, explicitly. The only way

to excuse what we're doing at the moment is to call it 'mere

aggregation' -- an exception which was intended to handle stuff like the

'freeware' CDs on the covers of magazines, distributing a bunch of

unrelated software. Not a coherent work combining software from

different sources into a single entity which works closely together as

one, and where one part is useless without the other.
The more that people claim it would be such a burden to split the

firmware from their driver because they're so closely interrelated, the

more they are arguing against the 'mere aggregation' defence, which was

tenuous enough in the first place.
And it isn't just the nutters. Fedora also wants to ship the firmware in

a separate package from the kernel -- since the alleged GPL violation is

such a _gratuitous_ risk given that we always use an initrd anyway, and

because people want to be able to do 'Free' spins which don't feature

the firmware at all, even in the source packages.
I strongly suspect we'd end up building the Fedora kernel from a special

'linux-2.6.2x-nofirmware.tar.bz2' tarball, rather than using the stock

tarballs if they continue to include the firmware. We do similar things
There are people who own copyright on firmware who refuse to put it into

the Linux source tree, because their lawyers don't believe the 'mere

aggregation' line, and believe that including it in the kernel source in

any form would require them to license it under the GPL.
But those same companies _would_ consider putting their firmware into a

non-GPL'd 'linux-firmware...
[ message continues ]

On Fri, 30 May 2008 02:04:18 +0300
For me, both inside kernel or on a separate tree would produce similar results.

Yet, a separate tree will be a little more painful.
One alternative to keep this at kernel -git tree would be to write a COPYING or

LICENSE file at firmware dir, explicitly stating that most of those firmwares

have proprietary licenses and are there just to make easier for kernel develoment.
Being in-tree or out kernel tree, we should explicitly state what license each

firmware uses, and having the license terms of proprietary firmwares there.
I would add a metatag at the .ihex file to reference to what license applies to

each firmware. Something like FIRMWARE_LICENSE("some vendor license #1"). For

those legacy firmwares where we don't know, we may simply add "unknown".
Cheers,

Mauro

--

Wait a moment, haven't you just described linux distribution?
I mean, if aggregation clause does not work for firmware in kernel,

why would it work for packages in distro?
(Actually, seeing some distro EULAs, I wished GPL infected whole
They can release the firmware under BSD 3-clause, and we can include

it in kernel, then.... right? (Or into linux-firmware or into whatever

package that comes handy).
--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--

That's an interesting question, which has concerned me in the past.

There are certainly those who would claim that the distribution _is_ a

collective work, and not just 'mere aggregation on a volume of a storage

or distribution medium'. Which poses interesting questions.
I think you might _just_ about get away with arguing to the contrary, as

long as you never refer to the distribution as a collective work which

is copyrightable in its own right, or try to put a EULA on it or

anything like that. At least it's _slightly_ more excusable in that case

than what we were talking about before.
Again, there's no definitive answer until/unless it comes to court. But

there's no _guarantee_ that a court would rule that what we're doing is

OK, even though it's a long-standing and universally accepted practice.

You can't apply reductio ad absurdum and declare that the whole

'collective work' part of §2 doesn't exist just because it might lead to
You may only include it in a GPL'd project if you can distribute the

source code in the preferred form for editing -- unless you claim that

the tightly intertwined combination of driver and firmware is "mere

aggregation on a volume of a storage medium", which many would say it

blatantly is not.
If, on the other hand, we have a separate repository where stuff only

has to be 'redistributable', then that would be OK even without source.
I'm working on reducing the technical barriers to having a separate

repository, to the point where it becomes silly not to do it like that.
--

dwmw2
--

Well, distos I seen, did try to claim whole distro is collective work,
Oops, you are right; I overlooked that.
--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--

While updating the bnx2 driver on a 2.6.24.7 based rpm and after reading

some of your messages...
commit df7f1ed6b85b936a4dd341c48e30aa207697997c

Author: Michael Chan <mchan@broadcom.com>

Date:   Tue Jan 29 21:38:06 2008 -0800
    [BNX2]: Update firmware.
    Update firmware to support programmable flow control.
    Signed-off-by: Michael Chan <mchan@broadcom.com>

    Signed-off-by: David S. Miller <davem@davemloft.net>
After this bnx2.c would be updated to have a:
MODULE_FIRMWARE_DEFAULT("df7f1ed6b85b936a4dd341c48e30aa207697997c");
to be obtained from firmware.git, and if some chip revisions needed

something different we could have a MODULE_FIRMWARE_PCI(vendor, product,

older-git-object) or something along these lines.
Some drivers could well prefer a more loose keying scheme, like

"foo-firmware-v2" and get the latest version of this from firmware.git.
- Arnaldo

--

There's definitely two schools of thought on this.  Sometimes firmware

changes (or adds) an interface.  If the kernel driver has to accommodate

new and old firmware, that adds complexity, and we all know that added

complexity means more bugs.  So I can definitely see some vendors

wanting to distribute their firmware with the kernel.
--

Intel are signing my paycheques ... these opinions are still mine

"Bill, look, we understand that you're interested in selling us this

operating system, but compare it to ours.  We can't possibly take such

a retrograde step."

--

driver should check fw version...
YH

--

From: "Yinghai Lu" <yhlu.kernel@gmail.com>
This alone is not a reason to rip the firmware out into a seperate

tree.  And I am absolutely not convinced that the cases where this

matters all universally even use firmware versions.
I've installed the wrong ipw2200 on several occaisions.
Furthermore, it's about distributing what works with what it's meant

to work with.  With this seperate scheme, I can still link in the

wrong firmware file (the driver doesn't check the firmware version

until it executes) and the driver won't work.  So this moves the

validation to run time, which users typically don't appreciate.
--

I agree. I hate to have two klibc (one for 32 bit, and one for 64bit)

to for initramfs to load FW for qlogic...
dwmw2 's new patches to put all fw in /firmware, and built them into

kernel could avoid that...
and could make the build process to check fw version to match with

driver in different kernel version later...
YH

--

At Thu, 29 May 2008 14:57:38 -0700,
OTOH, it doesn't give you any error at build time even if you forget

to put a firmware image beforehand.  The kernel continues to look for

a non-existing external firmware file.  In the old code, this can't

happen.
It's just a small drawback, and I still like the idea very well,

though.
Takashi

--

Perhaps we should make depmod also check all MODULE_FIRMWARE() and

complain about missing firmware which might be used? We could make it

(or something else) check for firmwares required by drivers built in to

the kernel, too.
--

dwmw2
--

Not all firmware has the ability to check the version :(
So while Arjan's goal would be nice, Matthew is right, this can't happen

for all types of firmware.
thanks,
greg k-h

--

Well for loaded or packaged firmware it can happen. Just stick a revision

number on the start of the firmware file and check it rather than load it

into the hardware in that specific driver.
Alan

--

Or append it to the name of the firmware file, in some cases.
--

dwmw2
--

Drivers with built in firmware usually don't.  Most don't actually have

even a version string they could check.  Why would they: the firmware

with the driver is the right one.   When I converted the aic94xx driver

to go from built in firmware to externally loaded, the first thing I had

to do was to give it a firmware version string in the binary.  It's this

type of problem that makes the conversion such a pain.
James
--

I like your idea, all the way to the point where you actually remove the

firmware file from the kernel tree :)
I think it's a good move to make the firmware files standalone and not

#include'd as a C header file, but it's just plain easier to ship them

with the kernel tree in a lot of cases.  $FOO-firmware packages in

Fedora prove other methods of firmware distribution are quite usable,

but that does not therefore imply that in-kernel built-in firmwares have

no utility.
Personally, living in an imaginary all-open-source world, I wouldn't

mind seeing firmware source for firmware built into drivers, a la

drivers/scsi/aic7xxx/aicasm/, living in the kernel tree.
If the firmware has a compatible license and is required for critical

operations like booting the machine, built-in firmware should remain an

option.  For certain embedded cases, I could certainly see that

in-kernel firmware being the best method for firmware distribution, for

both $Platform's users and $Platform's developers.
	Jeff
--

I certainly agree, pushing more and more into initrd just annoys the

hell out of me.
I'd argue to include everything needed to build (and esp cross build) an

initrd into the kernel - up until that point initrds are useless.
--

I tried to push for that two years ago.  I'd be more than happy to pull

that out of the freezer.
	-hpa

--

On Thu, 29 May 2008 16:39:48 -0700
Its kind of irrelevant if you need an initrd or not. The only question of

relevance is "does it get built when I type make all". Almost all Linux

users are using initrd without problem - because their distro ensures

"make install" and the packaged kernels do the right thing.
Alan

--

Obviously.  I'm equally obviously referring to klibc, which was designed

so that the resulting vmlinux/bzImage/... file contains the necessary

initramfs, regardless of issues like cross-compilation, draconian size

restrictions(*), and so forth.
	-hpa
(*) Not saying that a klibc-based initramfs is necessarily smaller than

the in-kernel code it replaces, but the total size is << than the size

of the kernel proper, which isn't true when using a full-featured libc.

--

True but with a vendor hat on thats not usually a problem on modern

systems and using glibc means less code to maintain, less special cases,

and more flexibility.
For embedded klibc may well be interesting.
Alan

--

For vendor hat meaning full-blown systems, yes that is true, but for

embedded, or even on some "real" platforms, that definitely matters.
Fundamentally, however, we're never going to have a full-blown libc

environment built out of the kernel tree, as its size would be

comparable or larger than the kernel itself.
	-hpa

--

Its my own convenience I'm serving here. I hardly ever do a local

install. And for the old machines a local build just isn't even an

option.
It's what benh said; I just want a single netbootable image. And cross

buildling initrds is just impossible - which makes the whole solution

useless.
--

Unless you actually use the feature added in the first patch of the

series, that enables you to build firmware images into your single

netbootable image, that is ;-)
--

Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/

Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

FSFLA Board Member       ¡Sé Libre! => http://www.fsfla.org/

Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}

--

hpa's klibc solution was cross-buildable IIRC.
	Jeff
--

Us kernel hackers tend to like self-contained netbootable kernels

that have everything needed to boot a machine all the way to a shell

prompt :-)
David's proposal however do provides for storing the firmwares in

the kernel image, so I have no objection there.
Ben.
--

I've been careful to ensure that what I'm doing is a benefit even

without that final step. But I still think that final step is useful
Well, 'compatible licence' is a loaded question. It takes a fairly

wilful misinterpretation of 'mere aggregation', IMHO, to see what we're

currently doing as legal -- but I was trying to avoid that discussion

since it tends to devolve into name-calling and nobody's _actually_

right until/unless it's decided by a court.
But sticking to the technical side -- with what I have now, it's

_easier_ to build external firmware into the kernel than it was before.

My original testing was done with a kernel with the libertas

'usb8388.bin' firmware built in to it, for example. That was never

possible before.
Having firmware files in a separate tarball doesn't prevent you from

building them into your vmlinux if you want to. And there are some

companies who wouldn't allow their firmware to be distributed in the

kernel source tree because it's under GPL, but _would_ consider putting

it in a separate 'kernel-firmware' repository instead. So this should

_also_ mean we can ship more firmware, more easily.
Hell, with git submodules you almost don't need to notice the

difference, do you? Just check out kernel-firmware as a subdirectory of

the source tree (or point CONFIG_BUILTIN_FIRMWARE_DIR at wherever you
It is not my intention to remove that possibility. I believe I have made

it _more_ feasible; not less.
--

dwmw2
--

I suspect many of the people contributing to this thread aren't on the

kernel-janitors list.  They're only seeing janitorial-style patches hit
Part of the problem is that whitespace fixing patches are treated like

they're real patches.  We get conflicts with real patches, they're pinged

like they're real patches, and the contributors name gets put in the

shortlog like it was a real patch.
I liked the trivial service that Rusty had setup.  Patch started getting

conflicts?  Dropped.  Pinged?  By an automated device, not by akpm.  We

didn't have contributor names back then, but maybe we should anonymise

whitespace patches -- just accept that something that could have been
Also, a lot of the trivial patches don't come across the janitors list

first, so shutting the project down will not, IMO, reduce the problem.
That's a good idea.  We'd all be happier if more people spent time on
There are some of those things going on in the current janitors project,

it's just they're drowned out by the noise.  I'd like to mention a few.
Mark Asselstine has been working to remove the last remnants of cli/sti

from the kernel.  I believe patches to get rid of them all are now

either merged or sitting in trees waiting to be merged.  I found him

receptive to feedback and willing to sit down and really analyse a

driver to figure out what was going on.  If he chooses to continue his

kernel hacking career, he'll be a great asset.
Julia Lawall has a fun tool that spots patterns which are buggy.  I've

worked on a number of patches with her recently where we compare

unsigned integers < 0.  Again, we need people to look at the piece of

code in context to figure out what the original author meant (not too

dissimilar from the coverity reports).
--

Intel are signing my paycheques ... these opinions are still mine

"Bill, look, we understand that you're interested in selling us this

operating system, but compare it to ours.  We can't possibly take such

a retrograde step."

--

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.
--

dwmw2
--

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
--

Hi James,
On Thu, May 29, 2008 at 12:01 AM, James Bottomley
I'm not sure what you expect to happen if we "shut down" the Janitors

project. The important janitorial work doesn't just magically

disappear. For example, we still need people for:
  - Fixing API misuse

  - Converting code from old APIs to new ones

  - Consolidating duplicate code

  - Fixing error handling code

  - Removing unused code

  - De-obfuscating code (e.g. removing bad macro magic, etc.)
And, quite frankly, I don't see what the big fuss is about. I know

we've had way too many "whitespace cleanup" patches in the past six

months or so, but can't we just NAK them politely and be done with it?
                        Pekka

--

I'm just outlining the possible solutions; shutting it down wasn't the

one I advocated. One can argue that janitorial changes with enough

intrinsic value tend to get done anyway regardless of whether we have
The problem is that there's something in the way all of this is working

that's causing politeness to get short shrift. In turn that's giving

lkml a larger than normal reputation for being a free for all dog fight

and discouraging potential contributors from coming forwards.
Appeals to be politer tend to only work in the short term (having given

quite a few of them).  I think we're developing a root cause problem in

the way we recruit people to work in the kernel and we have to think

about fixing it there.
James
--

Do we really have a problem recruiting people to work in the kernel? On

what do you base that observation?
On a similar note, do we have any real data on the question of whether

those who are volunteering the patches which raise so much ire would

_ever_ become productive members of the team, even if we were to nurture

them properly?
--

dwmw2
--

Yes, the median age of the MAINTAINERS is rising.  Not quite at the rate

of a year per year which would show we have practically no turn over,

but it is rising.
However, even if there were no recruitment problem at all, getting more

people involved is always better because it means more contributions.

And contributions (useful ones) are the lifeblood that moves the kernel
I don't think so.  But that's not really what I'm saying.  I'm saying we

need to make the process of encouraging useful contributors more

streamlined (as in less aggro on the mailing list).  If that involves

cutting out the less useful ones earlier, so be it.  If we can come up

with a better conversion process, that's great too.  I want to start the

discussion, not necessarily prescribe the solution.
James
--

From: James Bottomley <James.Bottomley@HansenPartnership.com>
This is not true at all.
If people are getting involved, just for the sake of being involved,

which there is strong evidence of, then it's not a positive thing.
We want people who are passionate about doing things with the

kernel, are self-motivated, and frankly don't need a ton of hand

holding and do not work on things that require absolutely no

thinking.
Look at anyone who is extremely nimble with the kernel, and ask them

what they worked on to get going with development.  Did Andrew Morton

fixup whitespace errors when he was starting to become familiar with

the tree?  Did I?  No, none of us did this stuff.  We read over the

code and learned how it worked, did a port, optimized a lookup

algorithm somewhere.
Consistently we see people turding with whitespace, and not breaking

out of that cycle.  That is a problem.

--

I came in knowing I wanted to do cpusets, and intentionally

picked off an "easier" target first -- overhauling the bitmap,

cpumask, nodemask apparatus -- in order to get up to speed.
--

                  I won't rest till it's the best ...

                  Programmer, Linux Scalability

                  Paul Jackson <pj@sgi.com> 1.940.382.4214

--

OK, I agree with this.  The problem with our current recruitment process

is that it seems to encourage non-useful contributions, which is what I
Right, so we need to start the newbies process at the point where

thought is required.   That's why I think bug hunting and reporting
Agreed.  And it's the problem I'd like to address in this discussion

item if it gets on the agenda.  Along with ways of encouraging more

useful contributions.
I'm not convinced we need to have a graduated programme where we try to

draw absolutely everybody in and up; as you say, people with interest

and passion will always draw themselves in naturally.  However, I do

think we need to provide contribution avenues for people who aren't

necessarily aiming to become full time kernel developers.
Like you, I find little value in whitespace patches (and much

annoyance); especially from people who never graduate from them.

However, if we get a user who's willing to test the kernel of the day on

their strange laptop every few days, report any problems or bugs they

see and work with people to fix them, that's a fantastically useful

service; it's relatively easy for them to do and if it's all they ever

do, it's enough to be very useful.
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.
James
--

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.
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.

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

Jiri Kosina

SUSE Labs

--

From my own experience: Last semester, I participated in a "Linux Kernel

Hacking Lab" which involved some smaller tasks (write a module which

presents a circular buffer in /proc; the same as char device; write

a very minimalistic file system, extend it to do something resembling

journalling, ...) and a larger project.
The first two tasks were easily done by reading Linux Device Drivers;

but after the file system task (2 weeks), more than half of the group

dropped out; probably because to get this task done you needed to dig at

least in the minix code.
The project I was later involved on was writing a file system, which

stores blocks with the same content only once. In a two months period

(with other lectures to attend to), we managed to produce such a thing;

but it was very unreliable (which reminds me, I am supposed to publish

the results of this project here)
Most problems resulted of a combination of not enough documentation

(filesystem/page cache/block device interaction) and "not digging deep

enough, so the kernel does not really do what we expected".
So, the code produced in this learning phase is not usable; but I

learned a lot from this. Restarting from scratch now would probably

yield some working code.
I probably would not have attended a lab titled like this ;)

--

Yep, sounds like a cool project, actually. I guess it could be very

useful for people like me that store many kernel trees around, and

sometimes run out of  disk space.

							Pavel

--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--

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
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.  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
Well, apart from bug fixing and testing, I don't either ... that's why

I'm proposing a discussion not a solution.
James
--

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,
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

--

In general, students are going to choose the easiest option ;-)
Perhaps you could try making the process of finding a kernel bug seem

more exciting?  I doubt that most kernel bugs are a simple as a missing =.

But even if they were, it's about the /process/ you take to get to that
Of course.  We have to make it sexier than that.
--

Intel are signing my paycheques ... these opinions are still mine

"Bill, look, we understand that you're interested in selling us this

operating system, but compare it to ours.  We can't possibly take such

a retrograde step."

--

Indeed. Large amount of kernel bugs is 'kernel doesn't work on this

hardware setup X, other hardware setups are not affected". That doesn't

sound too sexy either, unless you are unfortunate enough to have the piece

of hardware in question, of course.
--

Jiri Kosina

SUSE Labs

--

Well, if you test linux-next or -mm on a regular basis, you are almost

guaranteed to encounter a bug that manifests itself on your hardware, sooner

or later. :-)
Thanks,

Rafael

--

A newcomer is motivated to fix a non-trivial bug if his own setup is

seriously affected, no convenient workaround is possible, and it is

clear that nobody else is gong to fix the bug (e.g. because the code is

orphaned).
If you have funds, you may have ways to provide better motivators than this.

--

Stefan Richter

-=====-==--- -=-= ====-

http://arcgraph.de/sr/

--

I fully agree with this, you need passion and persistence - a will to

make a difference.
Also, the kernel is a lot more complex these days than it was like 5

years ago (not that I would know, since I'm not around that long :-),

and that just means you just get a better challenge!
Now getting such people is hard, I've been forever trying to get my

brother to take up a FOSS project, but the drive seems to be missing. If
I started by rewriting the page reclaim code ;-) you need to start

somewhere.
--

My raw numbers show that the number of individual kernel contributors

continues to increase with every release, so this might not be as much
I agree.
thanks,
greg k-h

--

From: Greg KH <greg@kroah.com>
And even based upon pure observation, I sometimes cannot keep up

with the patch submissions even if I lock myself up in my office

for a full straight 12 hours of a day.
That tells me that we are almost nearing a situation where we have

more than we need.
I think this "we need more developers" problem really does not exist

currently.  I see new people appearing all the time, and these are

the kind of new people we need, those who do useful work and aren't

in the "whitespace loop".

--

That depends on whether we are gradually adding to the pool

of developers, or seeing an increasing stream of newcomers

who supply a patch or two before disappearing again.
If you look at the list of contributors some old release for

which we have good data (say 2.6.16).  How many of those people

contributed to each of the following releases? Does the

decay curve look steeper or more gentle if you start from

a more recent release?
-Tony

--

I don't know, I haven't tracked the people individually that way, only

looked at the basic numbers of developers per release.
thanks,
greg k-h

--

On Wed, May 28, 2008 at 05:36:57PM -0700, Greg Kroah-Hartman wrote:

 > On Wed, May 28, 2008 at 04:23:52PM -0700, Luck, Tony wrote:

 > > > My raw numbers show that the number of individual kernel contributors

 > > > continues to increase with every release, so this might not be as much

 > > > of a problem as it's made out to be.

 > >

 > > That depends on whether we are gradually adding to the pool

 > > of developers, or seeing an increasing stream of newcomers

 > > who supply a patch or two before disappearing again.

 > >

 > > If you look at the list of contributors some old release for

 > > which we have good data (say 2.6.16).  How many of those people

 > > contributed to each of the following releases? Does the

 > > decay curve look steeper or more gentle if you start from

 > > a more recent release?

 >

 > I don't know, I haven't tracked the people individually that way, only

 > looked at the basic numbers of developers per release.
Are you just doing something like

 git log v2.6.16..v2.6.17 | grep ^Author: | sort -u| wc -l  
or do you have some script that maps addresses to people ?

One person may appear once in 2.6.20, and then a half dozen times

in 2.6.21 if they use multiple email addresses for example.

(Also, typos, and people using full hostnames in their sign-off's

 instead of email addresses skew this somewhat).
I'm guessing the latter, due to the graph thing you did. Pointers?
	Dave
--

http://www.codemonkey.org.uk

--

Yes, it's the later.  Jon Corbet has a great little python tool that we

have used to create the "who is writing the kernel" series of articles.

I've been using it to keep track of who maps to what email address and

for what company for a while now.
An older version can be found at:

	http://www.kernel.org/pub/linux/kernel/people/gregkh/kernel_history/

it's the 'gitdm' tool there.  I don't know if he has an updated version

around anywhere, I suppose as it looks like I'm doing the releases for

it, I can put up a new snapshot if people are really interested.
I also have "cleaned up" versions of the kernel log files for just the

reason you say above.  You would not believe the number of times some

people mispell their own name in a single kernel release...  That makes

it easier to do this kind of mapping.  The cleaned up logs are in that

directory as well.
thanks,
greg k-h

--

I took those cleaned up log files (which run from 2.6.11 to 2.6.22) and

created some new ones (raw, I didn't try to clean them) for 2.6.23, 2.6.24,

2.6.25 and 2.6.26-sofar.  Then I skimmed through looking for drive-by

contributors (defined as someone who contributes to just one release and

is then never heard from again).
The summary looks like this:

63 in version 2.6.11 never seen again

148 in version 2.6.12 never seen again

128 in version 2.6.13 never seen again

92 in version 2.6.14 never seen again

96 in version 2.6.15 never seen again

122 in version 2.6.16 never seen again

137 in version 2.6.17 never seen again

140 in version 2.6.18 never seen again

135 in version 2.6.19 never seen again

95 in version 2.6.20 never seen again

136 in version 2.6.21 never seen again

153 in version 2.6.22 never seen again

179 in version 2.6.23 never seen again

179 in version 2.6.24 never seen again

304 in version 2.6.25 never seen again
These numbers are somewhat exaggerated by typos (the "cleaned up" files

still have some problems in the "Author:" entry (which is the only one

I looked at).  People add or drop middle initials, or sometimes switch

between "Firstname Lastname" and "Lastname, Firstname", and there are

plenty of obviously garbled entries.
The numbers for the more recent releases may also include

people who are still in the community, but just don't contribute to

every release.
My script didn't look for people that contributed for two or more

releases and then disappeared.
You can skim through the full list at the bottom of this message

and make your own guesses at how much of this data is garbage.

Even if 3/4 of the names here can be discounted, that still leaves

over 500 people who came to us at one point with a patch that was

good enough to be applied and then they left.
-Tony
==== Scanning 2.6.11

Margit Schubert-While

Peter Maydell

Matthias-Christian Ott

Daniel E. Markle

Arkadiusz Miskiewicz

Jarno Paananen

Jonas Munsin

Tvrtko A. Ursulin

Ron Murray

Ulri...
[ message continues ]

On Fri, 30 May 2008 13:23:44 -0700

"Luck, Tony" <tony.luck@intel.com> wrote:
I was bored and went through the list.  When it comes to knowing many

kernel developers, I don't consider myself to have very wide-spread

contact with too many people.  But I was able to point out a few that
I'm 99% sure this is Artem Bityutskiy, who's listed in MAINTAINERS and
Nico is still active in the MTD community.  As active as the MTD
Seriously?  We had someone actually get a patch in with that name?
This is one of the many convolutions of Joern Engel's name.  He's
Tom pops up with an occasional sparc patch from time to time.  He's at
I knew Dave was getting fed up with some things but I didn't think he
Alex continues to post patches for some of the Tundra devices.
josh

--

We've had some great contributions from drive-bys down the years,

and I see that as a gain rather than a loss.  I suppose it's a

half-full versus half-empty perception.
Interesting list, but as you admit, yes, there are a lot of false
... anyone know what happened to that guy?
Hugh

--

Well, it can be a blessing and it can be a curse.  It mostly depends on

if anyone else is willing to take over the maintenance afterwards.
	-hpa

--

Totally agree.  If someone finds one bug, sends us a fix and leaves

as a happy customer that is a wonderful thing.
Here's the (much shorter) list of people that contributed to two

consecutive releases and then disappeared.  These people made at

least two contributions across a 3+ month period. In most cases

this moves them out of the "drive-by" category.
Probably some of them moved on to do different things (or were

promoted to manage people who still work on Linux).
-Tony
Scanning 2.6.11-2.6.12

Jeff Muizelaar

Mikkel Krautz

Eric Lammerts

Marcel Sebek

Brian Waite

Werner Almesberger

Giorgio Padrin

Samuel Jean

Hideaki YOSHIFUJI

Markus Bollinger

Catalin Boie

Jerome Forissier

Stephen Tweedie

John Lenz

Shannon Holland

15 never seen again
Scanning 2.6.12-2.6.13

Narendra Sankar

Steven Cole

Thomas Charbonnel

Steven Scholz

Jun Komuro

Jarkko Raja

Dely Sy

Qu Fuping

Lars Marowsky-Bree

Peter Zubaj

10 never seen again
Scanning 2.6.13-2.6.14

Nick Sillik

Giancarlo Formicuccia

M.Baris Demiray

Nick Wilson

Linda Xie

Victor Fusco

Jan Veldeman

Andreas Steinmetz

8 never seen again
Scanning 2.6.14-2.6.15

Kenneth Tan

Stuart Auchterlonie

Henk

Felix Blyakher

KOVACS Krisztian

Mike Kershaw

Adam Brooks

Hironobu Ishii

Abhay Salunke

9 never seen again
Scanning 2.6.15-2.6.16

Kylene Jo Hall

Alex Aizman

Rui Santos

Chris Humbert

Thomas Young

Daniel Marjamaki

Samir Bellabes

Gabriel A. Devenyi

Marcus Sundberg

9 never seen again
Scanning 2.6.16-2.6.17

Seiji Munetoh

Mattias Nordstrom

Per Liden

Horst Schirmeier

Marco Manenti

Marcin Rudowski

Holger Eitzenberger

Nippun Goel

Roberto Nibali

Karsten Suehring

10 never seen again
Scanning 2.6.17-2.6.18

Thomas Kleffel

Frank Gevaerts

Laurent Meyer

Catherine Zhang

Jean-Luc Leger

Peter Horton

Tomasz Kazmierczak

Dustin Kirkland

Mandy Kirkconnell

Bastiaan Jacques

David Hollister

Wu Fengguang

12 never seen again
Scanning 2.6.18-2.6.19

Manoj Naik

Toralf Foerster

Thiago Galesi

Chris Boot

matthieu...
[ message continues ]

There's an interesting unspoken assumption here that people who stop

contributing patches which end up in the Linux kernel mailing "no

longer working on the kernel", or "no longer working in Linux", or

"left the community", or (even more of a stretch) people that we have

somehow driven away or that we have failed because they didnt come

back.
	Original author of LILO, does networking research using the

	Linux kernel.  (Has shown up and presented papers at various
	Still working at Red Hat, my last knowledge was that he was in
	Member of IBM Linux Technology Center, Security Team.
	Was a member of the IBM Linux Technology Center, now working
	Member of the IBM Linux Technology Center, on leave to get an
	Git maintainer.  :-)
So lots of stories, and there are plenty of people who are still

working at a company doing Linux work; they're just not happening to

contribute to a kernel.  They might be fixing bugs for customers, or

forward porting Xen for an enterprise distro, or many other things

that are intimately related to the Linux kernel --- just not in ways

that result in patches into mainline.
So if we really want some hard numbers on how many kernel developers

we are "losing", we would probably have to try to contact some of

these people and see if they are willing to answer a survey.  But

given your numbers, I really don't think it's as big a problem as some

people make it out to be....
						- Ted

--

I know some of the names on the list which seem valid, but they are

still in the community at large they just aren't sending patches .. I'd

imagine not many of these people are gone from Linux, they're still

involved in some way.
(btw, Greg KH is listed under 2.6.25 .. )
Daniel
--

Well, you do know that the distribution of all of our users are:

	50% only contributed 1 patch

	25% contributed 2

	12% contributed 3

	6% contributed 4

and so on?
Our curve is leveling out much better now though.  For the whole 2.5

release, the top 30 people did over 80% of the work.  Now, the top 30

people are doing 30% of the work.
So it is getting much better, as long as we still continue to keep our

massive rate of change[1] that we have going, and huge number of

developers[2], we should be fine.
So this list doesn't necessarily mean anything is wrong, only that 50%

are one-time contributors.  And I think that shows we are easy to get a

change into our tree from just about anyone, not that we are driving

people away.
thanks,
greg k-h
[1] 7,000 lines added, 2,500 lines removed, 2,400 lines modified, per

day for all of the 2.6.25 release cycle.  That's insane.

[2] 2,598 unique developers from 2.6.20 to 2.6.25

--

On Fri, May 30, 2008 at 1:47 PM, Greg KH <greg@kroah.com> wrote:
"contributed" here means a patch was accepted.

This is measuring "attribution", not contribution.
Posting a patch is not trivial and (hopefully) takes a fair

amount of work to prepare for anyone not doing this full

time. I'm not talking about white space changes but

even trivial patches that require some testing.
It would be interesting to scrape the archives of linux-*

and netdev mailing lists to see who is submitting patches

(and how many) and compare that with how many the

same person gets "attribution" for. The fallout rate would
My guess is top 30 people are spending more time reviewing patches
In general I agree - I don't think the problem is as bad

as some people are claiming. But I want to acknowledge

it is a problem and I think jejb is right in how he is
I still don't buy this. I've been contributing to linux kernel since about

1999 and it's definitely not getting easier.  The size of SubmittingPatches

is one indicator of how much work it is to submit a patch.

SubmittingPatches is now 600 lines (3400+ words).
The large number of contributors says nothing about how easy or hard

it is to get a patch into the tree. I think it says more about how many

people are getting paid to work on linux or are exposed to linux.
My own experience with tulip driver certainly isn't one that encourages

people to submit more patches and stay involved. USB patches I've

submitted were trivial (hard to debug and required specific HW to test)

but did get accepted. The first IDE patch I submitted also got rejected

with an answer that didn't help:

   http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg22756.html
That last patch "Worked For Me" and Alan Cox argued for it but it

didn't get further attention. I mention these only because except

for tulip, I wasn't paid to submit or work on those patches.
The problem is with specific maintainers not having BW or interest

in the users' problems. I'm think...
[ message continues ]

This growth of SubmittingPatches and related documents also partly means

that we now have

   - more tools available for QA before posting,

   - more documentation on these tools,

   - more comprehensive documentation on the workflows.

To some degree, this should make contributions easier rather than harder.
It may of course also mean that some expectations are higher now, as you

are saying AFAIU.  However, with scarce reviewer base (and scarce early

testers base, compared to the whole userbase), it's not a bad thing for

the project health if patches, when first posted, already have a good

level of quality.  We want many good contributions, not just many

contributions.  Of course if there were many reviewers and many mentors,

than we could do with lower initial quality of submissions.

--

Stefan Richter

-=====-==--- -=-= =====

http://arcgraph.de/sr/

--

It depends how we see this. Having a lot of external contributors is

very good, as it implies that more and more people are getting used

to read and modify the code. What would be interesting would be to

check for people who where there on a regular basis then went away,

even though I admit is harder to find out.
Willy
--

On Wed, 28 May 2008 12:20:12 -0500
I've had some limited success with:
http://kernelnewbies.org/KernelProjects
One problem is that people end up beginning with a project but

for some reason stop working on it later - with no indication

as to whether the project ended up being too difficult, or they

ran out of time, or something else happened...
--

All rights reversed.

--

Isn't the kernel mentors project supposed to help us at least get

feedback on that problem (if not prevent it altogether)?
James
--

I think our mistake is the assumption that everyone who wants to contribute to

the kernel wants to code, or that everyone wants to end up at the top of the

major feature contributors list.  For lots of people, we're going to be that

experiment from college they never quite want to admit to later on in life.
Looking at the KernelProjects link, bugzilla is at the buttom and janitors is

at the top.  I've always thought the janitors project was important, but

maybe we want to change the emphasis around a bit.
The regressions page on kernelnewbies is out of date, and there are many more

howtos on coding than on bug hunting.  It doesn't mention linux-next

anywhere.
I'm not picking on kernelnewbies, it is one of our best resources.  But, going

back to James' ideas, introducing people to bug hunting is a better way to

involve them in the community.
Maintainers are easier to interact with when you send good bug reports along

with a clear way to reproduce it and perhaps a bisection
Getting all of the above is often 95% of the work of fixing it, people are

most likely to jump into the coding when they've found a bad patch and start

to wonder if they can fix it themselves.
Along those lines, how about a kernel bug hunting challenge.  The top

contributor(s) to creating bugzillas that get solved get a new pc, laptop,

high end graphics card, ssd device...whatever.  We could send the best

testers hardware that breaks most often...everyone wins.
Other prizes could include tickets to a linux conf of choice (not airline

tickets, just free entry).
One motivation here is to bring bug reporters from active distro communities

into testing mainline kernels as well.
-chris

--

My experience from handling both distro-reported and upstream-reported

bugs shows that these two worlds/communitites are really quite different

in their nature.
Bug reporters who report bug in the vanilla kernel are usually perfectly

fine when someone sends them patch to test, they don't have any problem

recompiling the patched kernel, testing, and reporting back.
This is not the case with distro kernel bug reporters at all. You usually

can't just tell them "hey, this patch might fix it, report back if it

does". Vast majority of theese users expect the kernel package built for

their distro to be provided, so that they can easily install it and test

it, but requiring any other effort usually doesn't work.
Just my $0.02.
--

Jiri Kosina

SUSE Labs

--

I guess this would be helped if we actually made compiling distro

kernel easy.
Default suse installation does not even contain gcc; I'm not sure if

we provide our kernel in easy-to-use git form, and I don't think many

suse people would be able to create kernel .rpm without help of

autobuild system... autobuild only works behind suse firewall and

buildservice is not really right answer either.
Having compile-me-kernel script that does all the neccessary steps of

compiling/installing distro kernel with custom patches would be great

way forward...
Plus, we do very little q&a on distro kernel w.r.t to non-standard

.config files. Improving that would be some work, but there would be

chance for 'disable CONFIG_NO_HZ and see if it helps' kind of

debugging.
Oh and having make prepare-kernel-for-this-distro in vanilla would

help a lot, too. Usually, vanilla boots and works on distro with

suitable config, but finding that config is not too easy.

							Pavel

--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--

As far as whitespace fixes, it seems we should just declare a flag day,

specifically, right before Linus releases 2.6.26 or .27 he'd run

"cleanfile" on the WHOLE TREE and check it in (either as one patch or

several.)
After that, one would either have to use "patch -l" to refresh patches

across the flag day, or I would write a reverse version of "cleanpatch"

(one which cleans the minus lines and the context instead of the output)

to fix them up.
Then the whole tree would be whitespace-clean, it would concentrate the

pain to a single event, and then we can go on with life.
	-hpa

--