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:
...
> If this proposal meets with approval, I am willing to do three things:
Sounds good for me.
>
> 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.
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 :-)
>
> 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
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Karsten Keil
SuSE Labs
ISDN development
"Eric S. Raymond" <[email protected]> writes:
>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
>Comments are solicited.
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 :
[...]
> What's wrong with:
>
[xml]
I'd rather use c/etags.
Seriously, it won't create maintainers automagically.
I don't see the benefit.
--
Ueimor
"Eric S. Raymond" wrote:
>
> 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:
>
Good!
> 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:
> 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.)
>
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
On Sat, Apr 21, 2001 at 04:38:59PM +0000, Henning P. Schmiedehausen wrote:
> What's wrong with:
[...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]>:
> 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)
Good point.
> 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)
Is there any kernel code that isn't GPLed?
> Instead of C: it is more important (IMHO) to include the module name.
That we get from the name of the file we're visiting, I think.
> 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).
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
Eric S. Raymond writes:
> 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.
It is nice to have a single file for grep. With the proposed
changes one would sometimes need to grep every file.
Albert D. Cahalan <[email protected]>:
> Eric S. Raymond writes:
>
> > 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.
>
> It is nice to have a single file for grep. With the proposed
> changes one would sometimes need to grep every file.
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
On Sat, 21 Apr 2001, Albert D. Cahalan wrote:
> Eric S. Raymond writes:
>
> > 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.
>
> 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]>:
> The real problem is that large part of the kernel has no permanent
> maintainers. Which makes the whole (overdesigned) idea completely moot.
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
Eric S. Raymond <[email protected]> ecrit :
[...]
> 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.
Y N
The kernel will perform better [ ] [ ]
Somebody will have less work [ ] [ ]
It's fun (TM) [ ] [ ]
--
Ueimor - cd /pub
Francois Romieu <[email protected]>:
> Y N
> The kernel will perform better [ ] [*]
> Somebody will have less work [*] [ ]
Yes, anybody trying to figure out how to get a fix made.
> It's fun (TM) [*] [ ]
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 ,
On Sat, 21 Apr 2001, Albert D. Cahalan wrote:
> Eric S. Raymond writes:
> > 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.
> It is nice to have a single file for grep. With the proposed
> changes one would sometimes need to grep every file.
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 |
+----------------------------------------------------------------+
Eric S. Raymond <[email protected]> ecrit :
> Francois Romieu <[email protected]>:
[...]
> > Somebody will have less work [*] [ ]
>
> Yes, anybody trying to figure out how to get a fix made.
Provided it's kept up-to-date. I.e. it calls for some tools (and these
require the suggested changes).
> > It's fun (TM) [*] [ ]
>
> Fun for me. I like solving global problems rather than just local ones.
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]>:
> Provided it's kept up-to-date. I.e. it calls for some tools (and these
> require the suggested changes).
Yes. I'll write the tools.
> 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.
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
> 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.
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..
> Is there any kernel code that isn't GPLed?
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.
> 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.
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
>>>>> "Henning" == Henning P Schmiedehausen <[email protected]> writes:
Henning> "Eric S. Raymond" <[email protected]> writes:
>> 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
>> Comments are solicited.
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]>:
> It scales perfectly.
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
Alan Cox <[email protected]>:
> 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
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
> 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.
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.
James W. Laferriere writes:
> On Sat, 21 Apr 2001, Albert D. Cahalan wrote:
>> Eric S. Raymond writes:
>>> 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.
>>
>> It is nice to have a single file for grep. With the proposed
>> changes one would sometimes need to grep every file.
>
> Find . -name "*Some-Name*" -type f -print | xargs grep 'Some-Info'
> Hate answering with just one line of credible info , But .
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.
>> Find . -name "*Some-Name*" -type f -print | xargs grep 'Some-Info'
>> Hate answering with just one line of credible info , But .
>
>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-----
> 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.
Which is 99% of the time for most users.
> >> Find . -name "*Some-Name*" -type f -print | xargs grep 'Some-Info'
> >> Hate answering with just one line of credible info , But .
> >
> >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: '
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.
Albert D. Cahalan <[email protected]>:
> 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.
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]> said:
> 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.
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
"Eric S. Raymond" <[email protected]> said:
> Subject: Re: Request for comment -- a better attribution system
>
> Return-Path: [email protected]
> Delivery-Date: Sat Apr 21 20:28:52 2001
> Return-Path: <[email protected]>
> Reply-To: [email protected]
> Mail-Followup-To: "Eric S. Raymond" <[email protected]>,
> "Albert D. Cahalan" <[email protected]>,
> CML2 <[email protected]>,
> [email protected]
> References: <[email protected]> <200104212023.f3LKN7P188973@sat
> ***urn.cs.uml.edu>
> Mime-Version: 1.0
> Content-Disposition: inline
> User-Agent: Mutt/1.2.5i
> In-Reply-To: <[email protected]>; from [email protected]
> ***ml.edu on Sat, Apr 21, 2001 at 04:23:06PM -0400
> Organization: Eric Conspiracy Secret Labs
> X-Eric-Conspiracy: There is no conspiracy
> Sender: [email protected]
> Precedence: bulk
> X-Mailing-List: [email protected]
>
> Albert D. Cahalan <[email protected]>:
[...]
> > It is nice to have a single file for grep. With the proposed
> > changes one would sometimes need to grep every file.
> 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.
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
"Eric S. Raymond" <[email protected]> said:
> Alan Cox <[email protected]>:
> > It scales perfectly.
> 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.
What makes you think your scheme will fare any differently?
[...]
> 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.
They post on LKM as last resort.
--
Horst von Brand [email protected]
Casilla 9G, Vin~a del Mar, Chile +56 32 672616
Alan Cox <[email protected]>:
> 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.
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)
Horst von Brand <[email protected]>:
> What makes you think your scheme will fare any differently?
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]>:
> 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).
Right you are.
> 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.
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.
> Question is, is it really worth it to create specialized tools for this
> very rare case?
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
On Sat, Apr 21, 2001 at 07:47:06PM -0400, Eric S. Raymond wrote:
> 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.
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'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">
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
Alan Cox wrote:
>
> > 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.
>
> 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
Alan Cox wrote:
>
> > Is there any kernel code that isn't GPLed?
No. Nearly all code is GPL or GPL compatible license.
>
> 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.
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.
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 :-)
On Sat, 21 Apr 2001, Eric S. Raymond wrote:
> 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.
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.
Albert D. Cahalan wrote:
>>>> Find . -name "*Some-Name*" -type f -print | xargs grep 'Some-Info'
>>>> Hate answering with just one line of credible info , But .
>>>>
>>>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: '
>>
>
>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!
Eric S. Raymond <[email protected]> ecrit :
[...]
> 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.
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...).
[...]
> > Question is, is it really worth it to create specialized tools for this
> > very rare case?
>
> Yes, if the rare case of supporting global cleanups actually needs to be a
> more common one. Think about that for a while, please.
I did and I feel we're building gaswork for nothing.
--
Ueimor
> 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.
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
On Sun, Apr 22, 2001 at 11:22:11AM +0100, Matthew Kirkwood wrote:
> 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.
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
> Where developers should send patches? To Linus/AC or to driver
> maintainer?
All of the above at random. Sometimes with a cc. Often to me/Linus if the
maintainer isnt responding.
> 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?
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.
> > 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)
>
> Is there any kernel code that isn't GPLed?
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
On Sun, 22 Apr 2001, Francois Romieu wrote:
> Look again at l-k archive: people do global changes (see VFS, network api,
> etc...).
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.
On Sun, 22 Apr 2001, Russell King wrote:
> > C: CONFIG_SCSI_BLARG
> > F: drivers/scsi/blarg.c
> > F: drivers/scsi/blarg.h
> And what would:
>
> C: CONFIG_ARM
>
> tell you? Nothing that is not described in the rest of the "ARM PORT"
> entry.
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.
> 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.
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
On Sun, Apr 22, 2001 at 02:42:29PM +0100, Matthew Kirkwood wrote:
> On Sun, 22 Apr 2001, Russell King wrote:
> > And what would:
> >
> > C: CONFIG_ARM
> >
> > tell you? Nothing that is not described in the rest of the "ARM PORT"
> > entry.
>
> True, but it would tell it to a script without intervention.
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
Russell King <[email protected]>:
> Could that be because there _is no_ maintainer for the config.in files?
> Therefore, splitting up the MAINTAINERS file achieves nothing.
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
Matthew Kirkwood <[email protected]>:
> Eric wants an easy way to find the owner of a CONFIG_ entry.
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]>:
> 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?
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
Giacomo A. Catenazzi <[email protected]>:
> 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.
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>
Alexander Viro <[email protected]>:
> 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.
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
>>>>> "Eric" == Eric S Raymond <[email protected]> writes:
Eric> Alan Cox <[email protected]>:
>> 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
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
[email protected] said:
> 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.
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]>:
> [email protected] said:
> > 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.
>
> Then you're going to conjure up maintainers for the code which is currently
> orphaned?
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
On Sun, 22 Apr 2001, Eric S. Raymond wrote:
> Alexander Viro <[email protected]>:
> > 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.
>
> 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.
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]>:
> Sigh... Would these broken things, by any chance, be "my grand ideas are
> not met with applause"?
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)
On Sun, 22 Apr 2001, Eric S. Raymond wrote:
> David Woodhouse <[email protected]>:
> > [email protected] said:
> > > 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.
> >
> > Then you're going to conjure up maintainers for the code which is currently
> > orphaned?
>
> That's a *really* hard problem. I don't know how to solve that one myself.
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/
On Sun, 22 Apr 2001, Eric S. Raymond wrote:
> 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.
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/
On Sun, 22 Apr 2001, Eric S. Raymond wrote:
> Alexander Viro <[email protected]>:
> > Sigh... Would these broken things, by any chance, be "my grand ideas are
> > not met with applause"?
>
> 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.
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]>:
> 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 ?
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
> 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.
I must have missed them 8)
Alan
> * you've ignored the robustness of design behind the UNIX kernel.
> These beasts keep going without falling apart even after serious injuries.
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
Horst von Brand <[email protected]>:
> Then explain to everybody here in a language they'll understand _what_ is
> wrong and _why_. Then propose a solution.
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
"Eric S. Raymond" <[email protected]> said:
> Alexander Viro <[email protected]>:
> > 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.
>
> 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.
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
On Sun, 22 Apr 2001, Eric S. Raymond wrote:
> Horst von Brand <[email protected]>:
> > Then explain to everybody here in a language they'll understand _what_ is
> > wrong and _why_. Then propose a solution.
>
> I'm on it. You'll see the results fairly shortly.
"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/
Hi,
mirabilos wrote:
> > > 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)
> > Is there any kernel code that isn't GPLed?
> It must not, due to the GPL viral effect.
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> |
+-------------------------------------------------------------+
On Sun, Apr 22, 2001 at 01:49:16PM -0300, Rik van Riel wrote:
> On Sun, 22 Apr 2001, Eric S. Raymond wrote:
> > David Woodhouse <[email protected]>:
> > > Then you're going to conjure up maintainers for the code which is currently
> > > orphaned?
> >
> > That's a *really* hard problem. I don't know how to solve that one myself.
>
> You could volunteer to maintain all the code you reveal
> to be orphaned ...
>
> *runs like hell*
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]>:
> 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.
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.
Roger Gammans <[email protected]> said:
[...]
> 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.
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.
> So Eric solution may get new maintainers to appear for orphaned code
> as 'if by magic'
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
> 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?
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
Alan Cox wrote:
>
> > 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?
>
> 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.
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
> 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.
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
On Tue, Apr 24, 2001 at 09:14:41AM -0400, Horst von Brand wrote:
> Roger Gammans <[email protected]> said:
>
> 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...
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]
On Sat, 21 Apr 2001, Albert D. Cahalan wrote:
> Eric S. Raymond writes:
>
> > 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.
>
> It is nice to have a single file for grep. With the proposed
> changes one would sometimes need to grep every file.
What about
grep `find . -name "MAINTAINERS"`
Anuradha
Roger Gammans <[email protected]>:
> On Tue, Apr 24, 2001 at 09:14:41AM -0400, Horst von Brand wrote:
> > 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...
>
> No. People who want to give something back to the linux community
> and want to find an option within their ability and time constariants.
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
Hi!
> > The real problem is that large part of the kernel has no permanent
> > maintainers. Which makes the whole (overdesigned) idea completely moot.
>
> One of the problems this