Re: Request for comment -- a better attribution system
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 - 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/
Re: Request for comment -- a better attribution system
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 - 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/
Re: Request for comment -- a better attribution system
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. -- http://www.tuxedo.org/~esr/;>Eric S. Raymond "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 - 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/
Re: Request for comment -- a better attribution system
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 - 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/
Re: Request for comment -- a better attribution system
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] - 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/
Re: [kbuild-devel] Request for comment -- a better attribution system
> 14USA-18X Serial Adapter. Distribution and/or > Modification of the > 15keyspan.c driver which includes this firmware, in whole > or in part, > 16requires 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 - 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/
Re: [kbuild-devel] Request for comment -- a better attribution system
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
3Generated from Keyspan firmware image Wed Jul 5 09:18:29
2000 EST
4This firmware is for the Keyspan USA-18X Serial Adaptor
5
6"The firmware contained herein as keyspan_usa18x_fw.h is
7Copyright (C) 1999-2000 Keyspan, A division of InnoSys
Incorporated
8("Keyspan"), as an unpublished work. This notice does
not imply
9unrestricted or public access to this firmware which is a
trade secret of
10Keyspan, and which may not be reproduced, used, sold or
transferred to any
11third party without Keyspan's prior written consent.
All Rights Reserved.
12
13This firmware may not be modified and may only be used
with the Keyspan
14USA-18X Serial Adapter. Distribution and/or
Modification of the
15keyspan.c driver which includes this firmware, in whole
or in part,
16requires 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
-
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/
Re: [kbuild-devel] Request for comment -- a better attribution system
> 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 - 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/
Re: Request for comment -- a better attribution system
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, ChileFax: +56 32 797513 - 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/
Re: Request for comment -- a better attribution system
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. -- http://www.tuxedo.org/~esr/;>Eric S. Raymond Never trust a man who praises compassion while pointing a gun at you. - 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/
Re: Request for comment -- a better attribution system
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] - 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/
Re: [kbuild-devel] Request for comment -- a better attribution system
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| +-+ - 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/
Re: [kbuild-devel] Request for comment -- a better attribution system
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 | +-+ - 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/
Re: Request for comment -- a better attribution system
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] - 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/
Re: Request for comment -- a better attribution system
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. - 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/
Re: Request for comment -- a better attribution system
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, ChileFax: +56 32 797513 - 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/
Re: [kbuild-devel] Request for comment -- a better attribution system
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 3Generated from Keyspan firmware image Wed Jul 5 09:18:29 2000 EST 4This firmware is for the Keyspan USA-18X Serial Adaptor 5 6The firmware contained herein as keyspan_usa18x_fw.h is 7Copyright (C) 1999-2000 Keyspan, A division of InnoSys Incorporated 8(Keyspan), as an unpublished work. This notice does not imply 9unrestricted or public access to this firmware which is a trade secret of 10Keyspan, and which may not be reproduced, used, sold or transferred to any 11third party without Keyspan's prior written consent. All Rights Reserved. 12 13This firmware may not be modified and may only be used with the Keyspan 14USA-18X Serial Adapter. Distribution and/or Modification of the 15keyspan.c driver which includes this firmware, in whole or in part, 16requires 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 - 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/
Re: [kbuild-devel] Request for comment -- a better attribution system
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 - 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/
Re: [kbuild-devel] Request for comment -- a better attribution system
14USA-18X Serial Adapter. Distribution and/or Modification of the 15keyspan.c driver which includes this firmware, in whole or in part, 16requires 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 - 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/
Re: Request for comment -- a better attribution system
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] - 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/
Re: Request for comment -- a better attribution system
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 - 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/
Re: Request for comment -- a better attribution system
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/ - 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/
Re: Request for comment -- a better attribution system
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. -- http://www.tuxedo.org/~esr/">Eric S. Raymond 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 - 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/
Re: Request for comment -- a better attribution system
"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 - 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/
Re: Request for comment -- a better attribution system
> * 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 - 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/
Re: Request for comment -- a better attribution system
> 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 - 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/
Re: Request for comment -- a better attribution system
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'. :-) -- http://www.tuxedo.org/~esr/">Eric S. Raymond 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 - 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/
Re: Request for comment -- a better attribution system
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. - 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/
Re: Request for comment -- a better attribution system
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/ - 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/
Re: Request for comment -- a better attribution system
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/ - 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/
Re: Request for comment -- a better attribution system
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. -- http://www.tuxedo.org/~esr/">Eric S. Raymond 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) - 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/
Re: Request for comment -- a better attribution system
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. - 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/
Re: Request for comment -- a better attribution system
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. -- http://www.tuxedo.org/~esr/">Eric S. Raymond 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 - 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/
Re: Request for comment -- a better attribution system
[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 - 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/
Re: Request for comment -- a better attribution system
> "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. -- http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Request for comment -- a better attribution system
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. -- http://www.tuxedo.org/~esr/">Eric S. Raymond "To disarm the people... was the best and most effectual way to enslave them." -- George Mason, speech of June 14, 1788 - 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/
Re: [kbuild-devel] Re: Request for comment -- a better attribution system
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. -- http://www.tuxedo.org/~esr/">Eric S. Raymond - 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/
Re: [kbuild-devel] Re: Request for comment -- a better attribution system
In article <[EMAIL PROTECTED]> you wrote: >> They post on LKM as last resort. > I tried that, too. It didn't work either. Most lklm readers ignore posts that look like trolls or are for proposals they disagree with. - 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/
Re: Request for comment -- a better attribution system
Matthew Kirkwood <[EMAIL PROTECTED]>: > Eric wants an easy way to find the owner of a CONFIG_ entry. No, I want much more than that. -- http://www.tuxedo.org/~esr/">Eric S. Raymond "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 - 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/
Re: Request for comment -- a better attribution system
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, -- http://www.tuxedo.org/~esr/">Eric S. Raymond "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 - 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/
Re: Request for comment -- a better attribution system
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. -- http://www.tuxedo.org/~esr/">Eric S. Raymond Nearly all men can stand adversity, but if you want to test a man's character, give him power. -- Abraham Lincoln - 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/
Re: [kbuild-devel] Re: Request for comment -- a better attribution system
Horst von Brand <[EMAIL PROTECTED]>: > > 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. I tried that, too. It didn't work either. -- http://www.tuxedo.org/~esr/">Eric S. Raymond As with the Christian religion, the worst advertisement for Socialism is its adherents. -- George Orwell - 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/
Re: Request for comment -- a better attribution system
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 - 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/
Re: Request for comment -- a better attribution system
> 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 - 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/
Re: Request for comment -- a better attribution system
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. - 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/
Re: Request for comment -- a better attribution system
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 - 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/
Re: Request for comment -- a better attribution system
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. - 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/
Re: [kbuild-devel] Re: Request for comment -- a better attribution system
In article [EMAIL PROTECTED] you wrote: They post on LKM as last resort. I tried that, too. It didn't work either. Most lklm readers ignore posts that look like trolls or are for proposals they disagree with. - 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/
Re: [kbuild-devel] Re: Request for comment -- a better attribution system
Horst von Brand [EMAIL PROTECTED]: 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. 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 - 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/
Re: Request for comment -- a better attribution system
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 - 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/
Re: Request for comment -- a better attribution system
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 - 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/
Re: Request for comment -- a better attribution system
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 - 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/
Re: [kbuild-devel] Re: Request for comment -- a better attribution system
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 - 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/
Re: Request for comment -- a better attribution system
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 - 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/
Re: Request for comment -- a better attribution system
"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 - 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/
Re: Request for comment -- a better attribution system
[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 - 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/
Re: Request for comment -- a better attribution system
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 - 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/
Re: Request for comment -- a better attribution system
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. - 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/
Re: Request for comment -- a better attribution system
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 - 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/
Re: Request for comment -- a better attribution system
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) - 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/
Re: Request for comment -- a better attribution system
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/ - 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/
Re: Request for comment -- a better attribution system
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/ - 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/
Re: Request for comment -- a better attribution system
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 - 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/
Re: Request for comment -- a better attribution system
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 - 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/
Re: Request for comment -- a better attribution system
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. - 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/
Re: Request for comment -- a better attribution system
* 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 - 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/
Re: Request for comment -- a better attribution system
"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 - 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/
Re: Request for comment -- a better attribution system
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 - 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/
Re: Request for comment -- a better attribution system
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/ - 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/
Re: Request for comment -- a better attribution system
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 imho 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. -- http://www.tuxedo.org/~esr/">Eric S. Raymond 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 - 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/
Re: Request for comment -- a better attribution system
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 imho 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 - 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/
Re: Request for comment -- a better attribution system
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 | | NetworkEngineer | 25416 22nd So | Give me Linux | | [EMAIL PROTECTED] | DesMoines WA 98198 | only on AXP | ++ - 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/
Re: Request for comment -- a better attribution system
Francois Romieu <[EMAIL PROTECTED]>: > YN > 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. -- http://www.tuxedo.org/~esr/">Eric S. Raymond "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) - 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/
Re: Request for comment -- a better attribution system
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. YN The kernel will perform better [ ] [ ] Somebody will have less work [ ] [ ] It's fun (TM)[ ] [ ] -- Ueimor - cd /pub - 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/
Re: Request for comment -- a better attribution system
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. -- http://www.tuxedo.org/~esr/">Eric S. Raymond What if you were an idiot, and what if you were a member of Congress? But I repeat myself. -- Mark Twain - 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/
Re: Request for comment -- a better attribution system
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. - 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/
Re: Request for comment -- a better attribution system
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. -- http://www.tuxedo.org/~esr/">Eric S. Raymond Never could an increase of comfort or security be a sufficient good to be bought at the price of liberty. -- Hillaire Belloc - 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/
Re: Request for comment -- a better attribution system
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. - 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/
Re: [kbuild-devel] Request for comment -- a better attribution system
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. -- http://www.tuxedo.org/~esr/">Eric S. Raymond A right is not what someone gives you; it's what no one can take from you. -- Ramsey Clark - 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/
Re: Request for comment -- a better attribution system
On Sat, Apr 21, 2001 at 04:38:59PM +, 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 - 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/
Re: [kbuild-devel] Request for comment -- a better attribution system
"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 - 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/
Re: Request for comment -- a better attribution system
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 - 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/
Re: Request for comment -- a better attribution system
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. > -- > http://www.tuxedo.org/~esr/">Eric S. Raymond > > 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 - 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/
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. -- http://www.tuxedo.org/~esr/">Eric S. Raymond 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/
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 - 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/
Re: Request for comment -- a better attribution system
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 - 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/
Re: Request for comment -- a better attribution system
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 - 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/
Re: [kbuild-devel] Request for comment -- a better attribution system
"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 - 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/
Re: Request for comment -- a better attribution system
On Sat, Apr 21, 2001 at 04:38:59PM +, 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 - 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/
Re: [kbuild-devel] Request for comment -- a better attribution system
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 - 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/
Re: Request for comment -- a better attribution system
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. - 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/
Re: Request for comment -- a better attribution system
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 - 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/
Re: Request for comment -- a better attribution system
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. - 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/
Re: Request for comment -- a better attribution system
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 - 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/
Re: Request for comment -- a better attribution system
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. YN The kernel will perform better [ ] [ ] Somebody will have less work [ ] [ ] It's fun (TM)[ ] [ ] -- Ueimor - cd /pub - 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/
Re: Request for comment -- a better attribution system
Francois Romieu [EMAIL PROTECTED]: YN 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) - 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/
Re: Request for comment -- a better attribution system
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 imho 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 - 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/
