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
My experience doesn't necessarily apply, because it is more
inside a big (and getting smaller ') company, SGI, but I've
seen schemes come and go to maintain such source attributes.
Only one thing works, in my world. A source control system.
If and when Linus and those he trusts decide to
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
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
Find . -name *Some-Name* -type f -print | xargs grep 'Some-Info'
Hate answering with just one line of credible info , But .
The above would grep every file. It takes 1 minute and 9.5 seconds.
So the distributed maintainer information does not scale well at all.
No it doesn't. It
Eric S. Raymond [EMAIL PROTECTED] said:
Subject: Re: Request for comment -- a better attribution system
Return-Path: [EMAIL PROTECTED]
Delivery-Date: Sat Apr 21 20:28:52 2001
Return-Path: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Mail-Followup-To: Eric S. Raymond [EMAIL PROTECTED],
On Thu, 19 Apr 2001, Kai Germaschewski wrote:
On Thu, 19 Apr 2001, Eric S. Raymond wrote:
The following patch cleans dead symbols out of the defconfigs in the 2.4.4pre4
source tree. It corrects a typo involving CONFIG_GEN_RTC. Another typo
involving CONFIG_SOUND_YMPCI doesn't need to be
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
James W. Laferriere writes:
On Sat, 21 Apr 2001, Albert D. Cahalan wrote:
Eric S. Raymond writes:
This is a proposal for an attribution metadata system in the Linux
kernel sources. The goal of the system is to make it easy for
people reading any given piece of code to identify the
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).
Again with due respect, you haven't gotten it yet. In fact, you've
got it exactly backwards. Unsurprising -- you're so magnificently
well adapted to the way things are that certain limiting assumptions
of the system you operate in have become invisible to you.
Oh Im quite aware of the
On Sun, Apr 22, 2001 at 11:22:11AM +0100, Matthew Kirkwood wrote:
C: CONFIG_SCSI_BLARG
tag to MAINTAINERS. If you _really_ insist, add an:
F: drivers/scsi/blarg.c
F: drivers/scsi/blarg.h
too. It removes the ambiguity inherent in the current system,
without adding an overengineered
12 matches
Mail list logo
