Request for comment -- a better attribution system

This is a proposal for an attribution metadata system in the Linux kernel sources. The goal of the system is to make it easy for people reading any given piece of code to identify the responsible maintainer. The motivation for this proposal is that the present system, a single top-level MAINTAINERS file, doesn't seem to be scaling well.

In this system, most files will contain a "map block". A map block is a metadata section embedded in a comment near the beginning of the file. Here is an example map block for my kxref.py tool:

# %Map
# T: CONFIG_ namespace cross-reference generator/analyzer # P: Eric S. Raymond <[email protected]>
# M: [email protected]
# L: [email protected]
# W: http://www.tuxedo.org/~esr/cml2
# D: Sat Apr 21 11:41:52 EDT 2001
# S: Maintained

And here's what a map block should look like in general:

%Map:
T: Description of this unit for map purposes
P: Person
M: Mail patches to
L: Mailing list that is relevant to this area
W: Web-page with status/info
C: Controlling configuration symbol
D: Date this meta-info was last updated
S: Status, one of the following:

Supported: Someone is actually paid to look after this.
Maintained: Someone actually looks after it.
Odd Fixes: It has a maintainer but they don't have time to do
much other than throw the odd patch in. See below..
Orphan: No current maintainer [but maybe you could take the
role as you write your new code].
Obsolete: Old code. Something tagged obsolete generally means
it has been replaced by a better system and you should be using that.

There may be more than one P: field per map block. There should be exactly one
M: field.

The D: field may have the special value `None' meaining that this map block was translated from old information which has not yet been confirmed with the responsible maintainer.

Note that this is the same set of conventions presently used in the MAINTAINERS file, with only the T:, D:, and C: fields being new. The contents of the C: field, if present, should be the name of the CONFIG_ symbol that controls the inclusion of this unit in a kernel.

(Map blocks are terminated by a blank line.)

Not every file need contain a map block. To locate the responsible maintainer for a file, use the following algorithm:

1. Look for a map block in the file itself.

2. Look for a file named %Map in the enclosing directory. Any map block in that file applies to the entire directory.

3. Look for a map block in the enclosing directory's README. Any map block in that file applies to the entire directory.

4. If you are at the root of the source tree, give up. Otherwise, move to the parent directory and goto step 2.

If this proposal meets with approval, I am willing to do three things:

1. Generate a patch to distribute the information presently in the MAINTAINERS file into map blocks and %Map files.

2. Write a tool for querying the map database.

3. (Background task, with which I would expect help) Chase down more map entries and verify information in old entries.

Thanks to Andreas Dilger for suggesting the basic idea.

Comments are solicited.

		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The day will come when the mystical generation of Jesus by the Supreme
Being as his father, in the womb of a virgin, will be classed with the
fable of the generation of Minerva in the brain of Jupiter.
	-- Thomas Jefferson, 1823

On Sat, Apr 21, 2001 at 11:49:42AM -0400, Eric S. Raymond wrote:
...

Sounds good for me.

Since C: is here, it would be superb if the make ...config tools have button to show this information, but since you maintain this stuff I'm sure that you allready think about this :-)

Karsten Keil
SuSE Labs
ISDN development

Hi Eric,

please not. If you really want to redo this, please use a simple XML markup. Let's not introduce another kind of markup if there is already a well distributed and working.

What's wrong with:

<MAP NAME="CONFIG_ namespace cross-reference generator/analyzer"

     URL="http://www.tuxedo.org/~esr/cml2"
     STATUS="Maintained"
     DATE="Sat Apr 21 11:41:52 EDT 2001">
 <MAINTAINER NAME="Eric S. Raymond"
             MAIL="[email protected]"/>
 <PATCHES DESC="Send all patches here."
          MAIL="[email protected]" />

<LIST MAIL="[email protected]"
DESC="List for developers"/>
<LIST MAIL="[email protected]"
DESC="List for users"/>
</MAP>

Regards
Henning

Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     [email protected]

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   [email protected]
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Henning P. Schmiedehausen <[email protected]> ecrit :
[...]

[xml]

I'd rather use c/etags.

Seriously, it won't create maintainers automagically. I don't see the benefit.

Ueimor

Good!

We should use the same filed name of CREDITS e.g. D: for Description. (maybe you can invert D: description and T: time of last update)

It whould nice also if we include the type of the license (GPL,...). This for a fast parsing (and maybe also to replace the few lines of license)

Instead of C: it is more important (IMHO) to include the module name. Maybe we can include both (modules name are always lower case). I think that the inclusion of the config option is not important ( considering that it can be easily parsed from the kaos' new makefiles).

giacomo

"Giacomo A. Catenazzi" <[email protected]> said:

[...]

If it's in-kernel, it is GPLed.

Horst von Brand                             [email protected]
Casilla 9G, Vin~a del Mar, Chile                               +56 32 672616

No if it is build into the kernel is GPL or GPL compatible. some PPP drivers can be built only as modules because of the linking restriction of GPL code to non GPL compatible code.
In kernel there are also some automatic generated file. GPL requires sources!

But this is off-topic for the main lkml.

giacomo

[...xml horror deleted...]

The myriads of external tools/libraries you will need (and that usually do not work properly, spewing out undecryptable error messages, or are currently not installed on your machine) and the near impossibility to process XML files with standard unix text tools in a meaningfull way?

-Andi

Giacomo A. Catenazzi <[email protected]>:

Good point.

Is there any kernel code that isn't GPLed?

That we get from the name of the file we're visiting, I think.

Interesting point. Maybe that field should drop out once we transition.

		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

A right is not what someone gives you; it's what no one can take from you. 
	-- Ramsey Clark

There are numerous bits that are dual licensed, some which are licensed under the BSD non-advertising type license and some of it licensed under the X license.

No. Nearly all code is GPL or GPL compatible license.

I resign my proposal. Kernel sources are clean. I confused with the (obsolete) libg++ which have file that start with GPL license, at the bottom of file I find the BSD license and sometime in the middle there is also some univesity license, thus libg++ users should scann all file to see the copyright. Luckly the linux code is more clean.

giacomo

It is nice to have a single file for grep. With the proposed changes one would sometimes need to grep every file.

The real problem is that large part of the kernel has no permanent maintainers. Which makes the whole (overdesigned) idea completely moot.

Alexander Viro <[email protected]>:

One of the problems this `overdesign' can help solve is actually identifying the parts that have semi-permanent maintainers, and the parts that don't.

One way to use the meta-information, for example, would be to use it to periodically poll maintainers to find out if they're still active.

Another is to be able to generate reports on exactly how much of the kernel is in "Maintained" or "Supported" status. I think it would be worth making this change just so we could know that.

		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

What if you were an idiot, and what if you were a member of Congress?
But I repeat myself.
        -- Mark Twain

There is no correlation between claimed and actual levels of supportedness. There are drivers with no-one supporting them that are common and thus get fixed very rapidly for example.

I actually prefer MAINTAINERS because it breaks things down by area and reflects the actual maintainership and areas covered. Something that per file does not

Question about patches you receive:
How many patch from Maintainer do you receive?
How many patch from non-Maintainer do you receive (for maintained code)? How many patch from non-Maintainer do you receive (for non maintained code)?
[I don't need absolute values (but only ratios) nor exact numbers, just for make
me an idea]

IMHO the problem show in this thead is:
Where developers should send patches? To Linus/AC or to driver maintainer?
ESR proposal enforces this last, but do all mainainers have always time for linux
developement? Should the maintainers be professional? Should Linus/AC reject
clean patches from non-maintainers? Do all maintainers read lkml?

I think the idea of ESR is nice for the normal .c codes. The [Cc]onfig.in and
Makefile are a very special case, and I think after the inclusion of new kbuild in linux kernel, the maintainement of these files will be not a big
issue, so I will not discuss this special case.

When I find a bug in a file, I check at the top of the file to find who is the
maintainer. Normally I found the address of maintainer, and I will use this address. Thus there is already some duplicate address (but the addresses
in MAINTAINER are sometime old, or missing).
I see ESR proposal as a clean up/standardization of the head of normal files.
This is the case of developer that need to contact a maintainer .

The top MAINTAINER it is needed for the normal user that find a bug (and that don't know the structure of kernel).

Thus my proposal: We implement the ESR proposal and we create a new MAINTAINER file that will list some bugs ML (for each subsystem). In this manner the life of not-developer user will be simplified and maybe we receive some more bug report.
Alternativelly we can generate MAINTAINER from ESR's map headers. In this case we should include this script in the Linus script to automagically create the i386 defconfig.

BTW ESR's last threads show us some other problem in linux developement style.
(or better: the inhomogenity of developement style of some part of kernel),
and we should convince him that the newer subsystem (and arch) should be really
developed as cathedral style (untill stabilization) or we will be flooded by big
kernel patches every few days.

giacomo

PS: reading again this email (and doing some additions), I see that we cannot
standardize maintainers (nor ESR proposal nor in the actual MAINTAINERS).
ESR proposal cannot give us the right solution. We should live with the incomplete MAINTAINERS file and missing maintainers.

BTW also in Debian we have problems with MIA (and very busy) maintainers,
but because we are free project, we should live with that (and no-files could
give us a solution) [in Debian MIA file, here the Date files of ESR proposal]

Thus ESR: If a maintainer did not reply to you (or if you don't find the maintainer name), you will be the tmp_maintainer of such files. Files could help us, but no so much to solve your (and maybe us future) problems.

giacomo

All of the above at random. Sometimes with a cc. Often to me/Linus if the maintainer isnt responding.

The scheme I work tends to be something like

If the patch is small and obviously correct and its not to Jes Sorensen's driver
Apply it to -ac

If the patch is more complex or changes design considerations
if it seems reasonably sane to apply
Apply to -ac
Cc change to maintainer
Mark not to go to Linus without maintainer approval
Bounce to maintainer if active
Apply if not active or not replying

If the patch changes fundamental things - eg syscall numbers, policy in kernel
Tell them to talk to Linus

And then there are a thousand specific other things like config.h include fixing typo fixes and such which don't quite follow the rule.

Giacomo A. Catenazzi <[email protected]>:

Aha! Somebody is actually *thinking* rather than having a conservative reflex. Yes, boys and girls, this is exactly how I planned to solve the I-want-to-be-able-to-grep-it problem.

Giacomo hasn't resolved the larger question of whether my distributed- attribution proposal is a good idea or not. What he *has* done is demonstrated that the resistance to it is mostly rationalized rather than rational. Otherwise somebody else would have seen this a lot sooner.

		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Alan Cox <[email protected]>:

Instead of arguing this point, I will demonstrate a solution with working code.

		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Strict gun laws are about as effective as strict drug laws...It pains
me to say this, but the NRA seems to be right: The cities and states
that have the toughest gun laws have the most murder and mayhem.
        -- Mike Royko, Chicago Tribune

Eric> Alan Cox <[email protected]>:

Eric> Instead of arguing this point, I will demonstrate a solution Eric> with working code. -- <a

A MAINTAINERS file does not need code, as Horst said, no more specialized tools!

Jes

Eric S. Raymond <[email protected]> ecrit :
[...]

Y N

The kernel will perform better   [ ]  [ ]
Somebody will have less work     [ ]  [ ]
It's fun (TM)                    [ ]  [ ]

Ueimor - cd /pub

Francois Romieu <[email protected]>:

Yes, anybody trying to figure out how to get a fix made.

Fun for me. I like solving global problems rather than just local ones.

		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

"Extremism in the defense of liberty is no vice; moderation in the
pursuit of justice is no virtue."
	-- Barry Goldwater (actually written by Karl Hess)

Hello Eric ,

Find . -name "*Some-Name*" -type f -print | xargs grep 'Some-Info' Hate answering with just one line of credible info , But .
Hth , JimL
+----------------------------------------------------------------+
| James W. Laferriere | System Techniques | Give me VMS |
| Network Engineer | 25416 22nd So | Give me Linux |
| [email protected] | DesMoines WA 98198 | only on AXP |
+----------------------------------------------------------------+

The above would grep every file. It takes 1 minute and 9.5 seconds. So the distributed maintainer information does not scale well at all.

No it doesn't. It allows you to search for files of a specific naming pattern and greps those. So if you needed to know the maintainers of all the config.in files, you say:

find . -name "*onfig.in" -type f -print | xargs grep 'P: '

If you need to know the maintainer(s) of a specific file or directory of files, simply direct your search there. The only problem occurs when you really don't know where to look - so then you search the entire kernel for the configuration option, and look wherever you find that.

I really don't see the problem.

--------------------------------------------------------------

from:     Jonathan "Chromatix" Morton
mail:     [email protected]  (not for attachments)
big-mail: [email protected]
uni-mail: [email protected]

The key to knowledge is not to rely on people to teach you it.

Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/

-----BEGIN GEEK CODE BLOCK-----
Version 3.12
GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*) -----END GEEK CODE BLOCK-----

Which is 99% of the time for most users.

That was an easy problem, and try it to see all the bad matches! This would be more normal:

find . -type f | xargs egrep -i8 '^[^A-Z]*[A-Z]: .*(net|ip|tcp|eth|ppp)'

That is not a nice and easy command for most people, and if it isn't exactly right you just wasted over a minute.

Eric *has* offered to write tools to simplify this. I would guess that it would be something like:

kgrep [-t description] [-p person] [-m mailto] [-l mailing-list] [-w webpage] [-c config symbol] [-d date] [-s status]

-b

Three things are certain:
Death, taxes, and lost data
Guess which has occurred.
- - - - - - - - - - - - - - - - - - - -
Patched Micro$oft servers are secure today . . . but tomorrow is another story!

Albert D. Cahalan <[email protected]>:

There is an easy solution to this which I will demonstrate with code.

		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Everything that is really great and inspiring is created by the
individual who can labor in freedom.
	-- Albert Einstein, in H. Eves Return to Mathematical Circles, 
		Boston: Prindle, Weber and Schmidt, 1988.

Eric S. Raymond <[email protected]> ecrit :

[...]

Provided it's kept up-to-date. I.e. it calls for some tools (and these require the suggested changes).

I'll only object that imvvvvho there is no global problem here:
* If user meets a serious problem, the maintainer will surely ask him to test some fix, to specify some point or whatever. Thanks to System, user will save 5 or 10 minutes. To be compared to the time spent with said maintainer or preparing the bug report.
* If user don't know how to submit and don't use some exotic driver, I bet he will start by posting to l-k and be eventually redirected.
* If user has identified problem with his FooBar SS6 adapter, chances are that he knows who he should reach.

I have no problem with it but I'm not sure it's *really* useful.

Ueimor

Francois Romieu <[email protected]>:

Yes. I'll write the tools.

Reducing friction costs and increasing accountability is always useful.

		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

No matter how one approaches the figures, one is forced to the rather
startling conclusion that the use of firearms in crime was very much
less when there were no controls of any sort and when anyone,
convicted criminal or lunatic, could buy any type of firearm without
restriction.  Half a century of strict controls on pistols has ended,
perversely, with a far greater use of this weapon in crime than ever
before.
        -- Colin Greenwood, in the study "Firearms Control", 1972

What about

grep find . -name "MAINTAINERS"

Anuradha

Hi!

Albert D. Cahalan <[email protected]>:

The right way to handle that is to have a report generator that does the grep for you, or if you like simply returns the concatenation of all the map blocks so you can grep that.

The point of distributing them is so they're close to the work units they describe, and are thus (a) easy to find, and (b) more likely to stay up to date.

		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Never could an increase of comfort or security be a sufficient good to be
bought at the price of liberty.
	-- Hillaire Belloc

[...]

Please, _no_ specialized-just-for-linux-kernel-hacking tools! Unix is great because it has _no_ such for-one-task-only tools, which you have to learn how to use each time a reason for using them comes around.

Horst von Brand                             [email protected]
Casilla 9G, Vin~a del Mar, Chile                               +56 32 672616

It scales perfectly. Most of the people you annoyed are _in_ the maintainers and credits file. The fundamental problem is identical regardless of what you change - people forget to update things unless there is motivation [1]

Alan
[1] as proof of this claim count the number of CREDIT file updates made shortly after the RH share offering..

Henning> Hi Eric,

Henning> please not. If you really want to redo this, please use a Henning> simple XML markup. Let's not introduce another kind of Henning> markup if there is already a well distributed and working.

Henning> What's wrong with:

DON'T! go there, please!

A) This sucks to write and maintain, B) it sucks for people bringing up Linux on a minimum system or new architecture because they don't want to have to install 217 XML and other tools to just be able to configure and build a basic kernel.

Jes

Alan Cox <[email protected]>:

I must say, in the most respectful way possible, "bullshit!"

Alan, if MAINTAINERS scaled perfectly I wouldn't have had to spend three months just trying to figure out who was reponsible for each of the [Cc]onfig.in files. And even with that amount of effort mostly failing.

You only think the present attribution system scales well because your position is, shall we say, *privileged*. Maintainers come to you; you don't normally have to try to track them down. Me, I *know* that Andreas Dilger identified a real problem, because I've barked my fscking shins on it. In two separate contexts now.

(There's a related rant I'm not ready to utter yet about how lkml's social machinery is very poorly adapted to solving problems that cross boundaries between different hackers' personal fiefdoms.)

I'm an unusually stubborn and persistent person, as you have cause to know. I really wonder how much good work we've lost because people less stubborn than me simply gave up on the friction costs of trying to identify the responsible person(s) for the bits they wanted to change.

Andreas saw the problem, and he also saw the solution. It's to make the structure of the attribution system match the structure of the code -- and of the social machine that surrounds the code.

		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

No one is bound to obey an unconstitutional law and no courts are bound
to enforce it.  
	-- 16 Am. Jur. Sec. 177 late 2d, Sec 256

99.9999% of problems don't involve querying the set of maintainers of Confg.in files. The system is optimised to the general case of queries people need to make. It also happens to be accessible to people who are not kernel gurus because it uses roughly English terms for the maintainership and area.

The .0001% case isnt interesting. Thats the difference between real world systems and theory.

What makes you think your scheme will fare any differently?

[...]

They post on LKM as last resort.

Horst von Brand                             [email protected]
Casilla 9G, Vin~a del Mar, Chile                               +56 32 672616

Horst von Brand <[email protected]>:

Design better matched to the group's workflow. But I'm not going to argue the point when I think I can demonstrate it. Watch this space.

		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Horst von Brand <[email protected]>:

I tried that, too. It didn't work either.

		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

As with the Christian religion, the worst advertisement for Socialism
is its adherents.
	-- George Orwell 

Alan Cox <[email protected]>:

Again with due respect, you haven't gotten it yet. In fact, you've got it exactly backwards. Unsurprising -- you're so magnificently well adapted to the way things are that certain limiting assumptions of the system you operate in have become invisible to you.

What you call a rare case is rare not because it *should* be rare but because the work practices and social mechanisms of lkml combine to heavily discourage improvements that cross jurisdictional boundaries.

This is a *problem*. I won't belabor the point, because I am certain that you'll believe the conclusion more if you figure it out yourself than if I tell you. Hint: think about long-term coherency issues in large codebases. Think hard.

		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

.. a government and its agents are under no general duty to 
provide public services, such as police protection, to any 
particular individual citizen...
        -- Warren v. District of Columbia, 444 A.2d 1 (D.C. App.181)

Oh Im quite aware of the limitations of the system. Even the _value_ of those limitations. I am not interested in the .001% because it excessively impacts the other 99.99% of the problemspace I do care about.

Z

I have a much simpler proposal, which appears to solve your immediate problem, and would keep most people happy -- add a:

C: CONFIG_SCSI_BLARG

tag to MAINTAINERS. If you _really_ insist, add an:

F: drivers/scsi/blarg.c
F: drivers/scsi/blarg.h

too. It removes the ambiguity inherent in the current system, without adding an overengineered solution with no obvious advantages.

Matthew.

And what would:

C: CONFIG_ARM

tell you? Nothing that is not described in the rest of the "ARM PORT" entry.

--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html

True, but it would tell it to a script without intervention.

Eric wants an easy way to find the owner of a CONFIG_ entry. True, the consensus seems to be that this isn't a particularly useful thing to do, but if it must be done, this seems like an eminently sane way to do it.

Matthew.

So we need a system to handle the thousand odd entries, a person to maintain each item and correct all the errors, processes for handling shared CONFIG_ name space, and procedures for handling registering new entries.

It says one thing 'WOMBAT'

Alan

I'll grant you that it does solve the "who owns a CONFIG_ symbol", but that is only one small problem - there's the bigger problem as to who owns each line of code. Are we going to start labelling each source code line as well?

I just don't see what this gets us - its safe to assume that any symbol in arch/*/config.in which isn't a driver is looked after by the architecture maintainer. If not, the architecture maintainer probably knows who does.

If the purpose of this "documentation" exercise for CONFIG_* symbols is just that, then shouldn't we be adding it to the Config.in files, rather than creating yet more files which will become out of sync with the configuration system? (maybe we are, but the suggestions I've seen appear to the contary).

--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html

Matthew Kirkwood <[email protected]>:

No, I want much more than that.

		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

"This country, with its institutions, belongs to the people who
inhabit it. Whenever they shall grow weary of the existing government,
they can exercise their constitutional right of amending it or their
revolutionary right to dismember it or overthrow it."
	-- Abraham Lincoln, 4 April 1861

Russell King <[email protected]>:

Per-file or per-directory should suffice, I think.

		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Nearly all men can stand adversity, but if you want to test a man's character,
give him power.
	-- Abraham Lincoln

It has been my observation that human organizations over time grow mechanisms for doing the routine (i.e., frequent) tasks quite efficiently, while sporadic tasks are usually handled in ad hoc, case by case ways, which can be very inefficient (and usually frustrating to the would-be user).

In our case, the whole kernel development system is quite adept at soaking up point patches (the bread-and-butter in LKM), while larger scope changes (like the one you are proposing, and also some cleanup patch I proposed a long while back, and the other scattered changes I've seen fly by) are very infrequent and so not handled at all well.

Question is, is it really worth it to create specialized tools for this very rare case? I suspect they would cost an enormous effort to create, and will rot away before use. The observation by Alan that an applied (and even a only proposed) patch will make somebody squeal if it steps on their toes is perhaps the best tool for finding interested parties we can hope for in a widely distributed, informal, and moreover ever changing development organization. The MAINTAINERS file itself (maintainace of which is _much_ less work than what you propose) is (by your own account IIRC) incomplete and out of date.

Horst von Brand                             [email protected]
Casilla 9G, Vin~a del Mar, Chile                               +56 32 672616

Horst von Brand <[email protected]>:

Right you are.

Indeed this is the case. I think such global cleanups are, in fact, less frequent than they should be precisely *because* lkml's social machinery discourages them.

Yes, if the rare case of supporting global cleanups actually needs to be a more common one. Think about that for a while, please.

		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Faith may be defined briefly as an illogical belief in the occurrence
of the improbable...A man full of faith is simply one who has lost (or
never had) the capacity for clear and realistic thought. He is not a
mere ass: he is actually ill.
	-- H. L. Mencken 

Eric S. Raymond <[email protected]> ecrit :
[...]

May be it's a good thing: I^H Joe Average has some bright idea, does a global cleanup, consume maintainers time. Problem: idea was not so bright or actually really low priority one. Make him loose some hours and he will think twice about the best way to spend time improving the kernel. If we see a growing number of entry in the credits file for global changes while drivers are not ported from 2.x to 2.x+2 (for example), there is be a *real* problem.
People get discouraged because of this ? I hope they'll never have to elaborate fixes for braindead hardware.
Look again at l-k archive: people do global changes (see VFS, network api, etc...).

[...]

I did and I feel we're building gaswork for nothing.

Ueimor

And then we have the situation when about a half of filesystems has no single maintainer - they are taken care of when needed, but that's it. We also have _no_ official maintainer of VFS, and that's the way it's gonna be.

Eric, it would save everyone a lot of time if you actually cared to pull your head out of your... theoretical constructions and spent some efforts figuring out how the things really work. Building infrastructure before you get familiar with the problem domain is generally considered harmful. That's precisely what you are doing. Trust me, it doesn't earn you any respect from people familiar with the problem.

Alexander Viro <[email protected]>:

I've had my nose rubbed in how things really work. That's why I want to fix the things that are broken about how things really work.

		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

"To disarm the people... was the best and most effectual way to enslave them."
        -- George Mason, speech of June 14, 1788

Then you're going to conjure up maintainers for the code which is currently orphaned?

For most stuff, the way to co-ordinate global changes is to discuss it on l-k. If there's an active maintainer for parts which are affected, and if they care, they'll respond to mail on l-k. That statement is a tautology with my definition of 'active maintainer'.

Bug reports are a red herring - users don't bother. They'll continue to sent idiotic bug reports to l-k for stuff which has already been reported and fixed, however we try to make life easy for them.

BTW, please try to ensure your .sig remains within the 4 lines recommended by RFC1855. I appreciate that it's randomly chosen - but I also believe that it's not beyond your capability to ensure that excessively long quotes are not selected by whatever script provides the text to your MUA. If your political statement du jour cannot be expressed in one or two lines, it's inappropriate to include in mail to public fora.

--
dwmw2

David Woodhouse <[email protected]>:

That's a *really* hard problem. I don't know how to solve that one myself.

There are, however, other things that can be done to improve the way things work. Two things in particular: (1) to lower the technical and social barriers to entry so that maintainers will conjure *themselves* up with more frequency, and (2) to ... hmm, no, on reflection I think won't say that explicitly. It would scare the conservatives too much.

However, if you think about it, you'll notice there's a common thread in all the proposals I've been making. If you still have trouble seeing it, remember that I hack social systems as much as I hack code. And consider lkml as a social machine. And consider -- carefully -- the things it is demonstrably poor at.

		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Of all tyrannies, a tyranny exercised for the good of its victims may
be the most oppressive. It may be better to live under robber barons
than under omnipotent moral busybodies. The robber baron's cruelty may
sometimes sleep, his cupidity may at some point be satiated; but those
who torment us for our own good will torment us without end, for they
do so with the approval of their consciences.
	-- C. S. Lewis

You could volunteer to maintain all the code you reveal to be orphaned ...

*runs like hell*

cheers,

Rik
--
Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose...

		http://www.surriel.com/

http://www.conectiva.com/ http://distro.conectiva.com.br/

I'm not sure Eric would have to.

It's entirley possible the problem will solve itself when/if people like myself who hang around the edge of kernel dev , find their favourite piece of kernel has no maintainer - and volunteer.

So Eric solution may get new maintainers to appear for orphaned code as 'if by magic'

Alternatively not, of course.

TTFN

Roger
     Think of the mess on the carpet. Sensible people do all their
     demon-summoning in the garage, which you can just hose down afterwards.
        --     [email protected]

Roger Gammans <[email protected]> said:

[...]

What stops you right now from to trying to find the maintainer(s) and work with them on that very same piece of code? If nobody shows up, you could take over if need be.

People who want to take over "because it is s00 k3w1 to be a maintainer" with no real interest in the code, just in the fact that it is orphaned...

Dr. Horst H. von Brand                       mailto:[email protected]
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

No. People who want to give something back to the linux community and want to find an option within their ability and time constariants.

TTFN

Roger
     Think of the mess on the carpet. Sensible people do all their
     demon-summoning in the garage, which you can just hose down afterwards.
        --     [email protected]

Roger Gammans <[email protected]>:

Indeed. Beware elitism. If lkml become a closed society, it will become a dead one shortly thereafter.

		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

"The great object is, that every man be armed. [...] 
Every one who is able may have a gun."
        -- Patrick Henry, speech of June 14 1788

Roger Gammans <[email protected]>:

This is part of my intention.

		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Never trust a man who praises compassion while pointing a gun at you.

Sigh... Would these broken things, by any chance, be "my grand ideas are not met with applause"?

Take it from a guy who've done quite a few global changes: they are pretty much doable, but spamming maintainers with requests to support your k3wl ideas is not a way to go. All you are getting that way is a bunch of procmail rules.

Everyone who had been on l-k for more than a couple of months had seen $BIGNUM of "visionary" lusers with grand schemes of Changing The World(tm) and monumental lack of desire to learn. Until you demonstrate that you understand what you are "fixing" - don't expect special treatment.

Alexander Viro <[email protected]>:

Nope. Not at all. Stay tuned, because I'll explain.

And before you write me off as one of the $BIGNUM clueless visionaries, you might do well to remember that I actually *have* radically changed the world lkml operates in. At least twice.

		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

In the absence of any evidence tending to show that possession 
or use of a 'shotgun having a barrel of less than eighteen inches 
in length' at this time has some reasonable relationship to the 
preservation or efficiency of a well regulated militia, we cannot 
say that the Second Amendment guarantees the right to keep and bear 
such an instrument. [...] The Militia comprised all males 
physically capable of acting in concert for the common defense.  
        -- Majority Supreme Court opinion in "U.S. vs. Miller" (1939)

Let me see ...

1) fetchmail, allowing dialup users to get lkml
2) getting snake.thyrsus.com out of ORBS and starting the mother of all lkml threads

Did I forget anything ?

Rik
--
Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose...

		http://www.surriel.com/

http://www.conectiva.com/ http://distro.conectiva.com.br/

So had certain wa.us-based company. If you refer to your "Cathedral
and Bazaar" - pardon me the bluntness, but it doesn't speak well of your clue level. L-k is not a place for detailed analysis of that text, so let me just point to the fact that
* you've ignored the robustness of design behind the UNIX kernel.
These beasts keep going without falling apart even after serious injuries.
* you've ignored another factor - maintainer with a taste and ability
to say "no".
* you've made a completely unwarranted assumption - that widely-used
and available code actually gets reviewed by many people. It's demonstrably false.

	Ability to do PR != having a shred of clue in other areas.

I'm sure that you can come up with relevant examples yourself.

Rik van Riel <[email protected]>:

Yes, Rik, you did. It's not snake', it's snark'.

:-)

		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Freedom, morality, and the human dignity of the individual consists
precisely in this; that he does good not because he is forced to do
so, but because he freely conceives it, wants it, and loves it.
	-- Mikhail Bakunin 

I must have missed them 8)

Alan

Do you mean design or operation? In fact UNIX design has a number of serious errors/problems, we just have gotten accustomed to it so much that we don't care any more. Here the robustness is in fact inertia.

Robust operation is possible with any halfway cleanly designed system, cf. VMS.

Olaf

Then explain to everybody here in a language they'll understand _what_ is wrong and _why_. Then propose a solution. I for one am not convinced you have a "what", let alone a "why". And AFAIKS your solution will be an enormous burden to maintain if it is not to rot away in a very short time.

Horst von Brand                             [email protected]
Casilla 9G, Vin~a del Mar, Chile                               +56 32 672616

Horst von Brand <[email protected]>:

I'm on it. You'll see the results fairly shortly.

		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Strict gun laws are about as effective as strict drug laws...It pains
me to say this, but the NRA seems to be right: The cities and states
that have the toughest gun laws have the most murder and mayhem.
        -- Mike Royko, Chicago Tribune

"Here, have this solution. I'm sure there must be a problem for it."

Rik
--
Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose...

		http://www.surriel.com/

http://www.conectiva.com/ http://distro.conectiva.com.br/

1. If I install CML2 and go directly to "make xconfig", it deduces it needs to set top level options because some of the low level options are set. For example SCSI enabled because some SCSI device is set or hot plug because PCMCIA is set...because some PCMCIA device is set. The _problem_ is...none of these options were set in the CML1 generated .config file... and it _extremely_ tedious to use xconfig to clear out all the cruft.

A much better (but not yet right) way is to use "make ttyconfig" to quickly generate config.out from .config relatively fewer errors and ability to say no at a top level and cause all the lower level stuff to go away. make ttyconfig seems to parse the .config file in a different (and better) order.

Suggestion: On the first pass of CML2 processing through .config, before first config.out created, trust the top level setting and ignore lower level settings if top setting off.

2. So after some playing around, I want to go back to CML1. But the .config generated by CML2 is not compatible. I don't know if it's supposed to be but there's lots of problems.

Suggestion: Save your .config before you play with this stuff.

Bottom line: looks promising but I still haven't gotten a good compile from it, yet.

jeff

jeff millar <[email protected]>:

I'm finding this report very puzzling. Both front ends parse the .config in exactly the same order. In fact, it's done by the same code.

Because of the order tree traversal is done, I think ttyconfig should give you the effect you want.

The config.out isn't exactly compatible; it has explicit CONFIG_FOO=n settings in it. The .config file generated from that by configtrans should be, however; if it's not that's a bug. Can you send me your "incompatible" .config so I can see the problems?

		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Never trust a man who praises compassion while pointing a gun at you.

Could that be because there _is no_ maintainer for the config.in files? Therefore, splitting up the MAINTAINERS file achieves nothing.

However, for the specific times that you've unfortunately come across the problem, and one of the times it was to do with the ARM config.in file, I can definitely say that the information _has_ been in the maintainers file, and it _is_ up to date. Here, let me give an example:

ARM PORT

P:      Russell King
M:      [email protected]
L:      [email protected]
W:      http://www.arm.linux.org.uk/
S:      Maintained

I don't think that you can say that the MAINTAINERS file has failed in this case, and cutting it up into little pieces solves precisely nothing.

--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html

What is wrong with that is that it's serious overkill.
In particular, this application does not need the ability to nest tags, so what remains is a linear sequence of name=value pairs and the complicated syntax buys you nothing.

(More formally: it doesn't need a context-free language, a regular language is enough.)

Eric's suggestion is powerful enough to do the job and can be parsed with one line of sed script.

The useful thing in your proposal is the ability to give multiple attributes to one item, e.g. mail="addr" desc="addr". Even this can be achieved much easier with a bit of syntactical convention, like always giving mail addresses in <> with the rest of the line being comment. Most of the stuff is for human consumption only anyway.

Olaf

With the proposed changes it's nearly trivial to build the traditional MAINTAINERS file with a Makefile rule, so you've lost nothing. Plus you get the additional info (which the collecting script, two lines of sed in my estimate, would duly include[1]) which _file_ actually is maintained by whom.

Which makes e.g. coordinating patches and bug reporting much easier.

Olaf

[1] Although Eric would probably rather want to use a database querying tool at this point :-)

It must not, due to the GPL viral effect.

But I know of atleast the BSD compress module.
Because of the licensing it only can be compiled
as a module, so it's not part of the kernel which
if GPL'ed.

-mirabilos

Russell King <[email protected]>:

It's not just splitting up the file that I'm advocating. However, as I said, I'm going to stop arguing and demonstrate,

		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

"One of the ordinary modes, by which tyrants accomplish their purposes
without resistance, is, by disarming the people, and making it an
offense to keep arms."
        -- Constitutional scholar and Supreme Court Justice Joseph Story, 1840

Hi,

Well, would it be possible to create some module under LGPL, and then have included it into the kernel? Maybe it needs to maintain the LGPL version out of the kernel, and transform a copy to the GPL before submitting?

Or what about using a "twin-licence" that states "you can apply GPL or $another_licence, whichever you want"?

And what about real "public domain" software, where the author gave up all rights? (AFAIK, this is not legally possible in the German copyright laws, as you can't licence uses that'll be invented in the future).

markus, not a lawyer

Markus Schaber -- http://www.schabi.de/ -- ICQ: 22042130
+-------------------------------------------------------------+
| Allgemeine Sig-Verletzung 0815/4711  <nicht OK> <Erbrechen> |
+-------------------------------------------------------------+

There is kernel code under a whole variety of licenses. When linked together the resulting work is GPL but many of the pieces used on their own or in conjunction with different code are not GPL.

Alan

Unfortunatelly there are exeptions:
the old ppp driver (only lickable to GPL kernel).
and drivers/usb/serial/keyspan_usa18x_fw.h:
1 /* keyspan_usa18x_fw.h
2
3 Generated from Keyspan firmware image Wed Jul 5 09:18:29
2000 EST
4 This firmware is for the Keyspan USA-18X Serial Adaptor
5
6 "The firmware contained herein as keyspan_usa18x_fw.h is
7 Copyright (C) 1999-2000 Keyspan, A division of InnoSys
Incorporated
8 ("Keyspan"), as an unpublished work. This notice does
not imply
9 unrestricted or public access to this firmware which is a
trade secret of
10 Keyspan, and which may not be reproduced, used, sold or
transferred to any
11 third party without Keyspan's prior written consent.
All Rights Reserved.
12
13 This firmware may not be modified and may only be used
with the Keyspan
14 USA-18X Serial Adapter. Distribution and/or
Modification of the
15 keyspan.c driver which includes this firmware, in whole
or in part,
16 requires the inclusion of this statement."
17
18 */
with a surelly non-free/non-GPL license.

Maybe we should, as in tetex, check every license in every file, to remove
the non-free files.
[But anyone (not-M$) will sue us?]

giacomo

That one is being sorted out currently. The firmware itself is fine (its mere aggregation) but there are some problems with the firmware distribution aspects of it.

Going through checking licensing is generally a good idea. Its something that becomes more important over time and people become more fussy about with unclear cases (trn, tin, getty-ps for example are probably non free apps but people assume they are 'free software'). Older versions of glibc (2.1 etc) have some odd licensing bits in one area