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 PROTEC
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 somethi
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
> > maintain
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 somethi
> 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 current
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 varie
> 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 tog
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 fi
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
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
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 p
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 su
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 abo
"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
> * 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
> 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-ker
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'.
:-)
--
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 $B
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
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
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 tha
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
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
[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
> "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 poi
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 wa
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 refl
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
th
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 gr
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,
--
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
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)
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 inter
> 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 maint
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 interv
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 s
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
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 respon
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 solvi
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
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 mainta
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
> > maintai
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
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
>
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
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 yo
"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
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
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.
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 MAINTAI
50 matches
Mail list logo
