From: Tom Rini <trini@kernel.crashing.org>
To: Nicolas Pitre <nico@cam.org>
Cc: "Eric S. Raymond" <esr@thyrsus.com>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
"Albert D. Cahalan" <acahalan@cs.uml.edu>,
Matthew Wilcox <willy@ldl.fc.hp.com>,
james rich <james.rich@m.cc.utah.edu>,
lkml <linux-kernel@vger.kernel.org>,
parisc-linux@parisc-linux.org
Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
Date: Fri, 20 Apr 2001 11:55:01 -0700 [thread overview]
Message-ID: <20010420115501.A13403@opus.bloom.county> (raw)
In-Reply-To: <20010420112042.Z13403@opus.bloom.county> <Pine.LNX.4.33.0104201440580.12186-100000@xanadu.home>
In-Reply-To: <Pine.LNX.4.33.0104201440580.12186-100000@xanadu.home>; from nico@cam.org on Fri, Apr 20, 2001 at 02:48:18PM -0400
On Fri, Apr 20, 2001 at 02:48:18PM -0400, Nicolas Pitre wrote:
>
>
> On Fri, 20 Apr 2001, Tom Rini wrote:
>
> > On Fri, Apr 20, 2001 at 12:35:12PM -0400, Nicolas Pitre wrote:
> >
> > > Why not having everybody's tree consistent with themselves and have whatever
> > > CONFIGURE_* symbols and help text be merged along with the very code it
> > > refers to? It's worthless to have config symbols be merged into Linus' or
> > > Alan's tree if the code isn't there (yet). It simply makes no sense.
> >
> > Well, this depends a lot on a) The project to be merged (arch, mtd, whatever)
> > and b) how far something has gotten in being merged someplace else, and of
> > course c) the maintainer(s). Whatever the exact case, and in general, it
> > should be handled via the maintainer. Why? They maintain the code.
>
> Therefore it's the maintainer's job to submit coherent patches and accept to
> see inconsistent CONFIG_* references be removed from the official tree until
> further patch submission is due. It's only a question of discipline.
> Otherwise how can you distinguish between dead wood which must be removed
> and potentially valid symbols referring to code existing only in a remote
> tree?
Er, I think we agree, but I'm not sure. :)
The only people who actually know the difference between dead wood and partily
merged code are the maintainers. IMHO it's silly to remove a piece of code
like:
#ifdef CONFIG_SOMETHING_NOT_MERGED
...
#endif
If the rest of the code, which would make the above useful is heading toward
Linus.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
next prev parent reply other threads:[~2001-04-20 18:58 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-04-20 2:36 OK, let's try cleaning up another nit. Is anyone paying attention? Matthew Wilcox
2001-04-20 3:00 ` Eric S. Raymond
2001-04-20 3:17 ` Matthew Wilcox
2001-04-20 4:07 ` james rich
2001-04-20 4:19 ` Matthew Wilcox
2001-04-20 4:52 ` Albert D. Cahalan
2001-04-20 5:17 ` Rik van Riel
2001-04-20 13:13 ` [parisc-linux] " Alan Cox
2001-04-20 13:35 ` Eric S. Raymond
2001-04-20 13:43 ` Alan Cox
2001-04-20 13:53 ` Eric S. Raymond
2001-04-20 14:03 ` Alan Cox
2001-04-20 14:19 ` Eric S. Raymond
2001-04-20 14:44 ` Alan Cox
2001-04-20 14:59 ` Eric S. Raymond
2001-04-20 15:51 ` Tom Rini
2001-04-20 16:06 ` Jeff Garzik
2001-04-20 16:15 ` Bob McElrath
2001-04-20 16:21 ` Matthew Wilcox
2001-04-20 19:00 ` Jeff Dike
2001-04-20 18:47 ` Matthew Wilcox
2001-04-20 21:55 ` Jeff Dike
2001-04-20 18:53 ` Jes Sorensen
2001-04-20 16:26 ` Jeff Garzik
2001-04-20 16:35 ` Nicolas Pitre
2001-04-20 16:50 ` Eric S. Raymond
2001-04-20 19:08 ` Russell King
2001-04-21 3:08 ` Tom Leete
2001-04-21 8:53 ` [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone rmk
2001-04-20 18:20 ` [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? Tom Rini
2001-04-20 18:48 ` Nicolas Pitre
2001-04-20 18:55 ` Tom Rini [this message]
2001-04-20 21:19 ` David Woodhouse
2001-04-20 21:24 ` Eric S. Raymond
2001-04-20 21:29 ` David Woodhouse
2001-04-20 21:35 ` Eric S. Raymond
2001-04-20 22:53 ` Alan Cox
2001-04-21 0:37 ` Eric S. Raymond
2001-04-21 23:39 ` Jes Sorensen
2001-04-21 12:32 ` David Woodhouse
2001-04-23 21:12 ` [patch] fix broken symbols (was Re: OK, let's try ...) Arjan van de Ven
2001-04-20 21:39 ` [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? David Woodhouse
2001-04-21 0:24 ` Eric S. Raymond
2001-04-20 18:50 ` Russell King
2001-04-20 21:23 ` Andreas Dilger
2001-04-21 0:52 ` Proposal for better attribution structure Eric S. Raymond
2001-04-20 8:19 ` OK, let's try cleaning up another nit. Is anyone paying attention? David Woodhouse
2001-04-20 19:47 ` Eric S. Raymond
2001-04-20 20:00 ` Matthew Wilcox
2001-04-20 20:13 ` Eric S. Raymond
2001-04-20 20:55 ` Alan Cox
2001-04-21 6:48 ` [parisc-linux] " Grant Grundler
2001-04-21 14:52 ` Eric S. Raymond
2001-04-20 13:08 ` Alan Cox
2001-04-20 13:18 ` Eric S. Raymond
2001-07-29 10:47 ` Riley Williams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20010420115501.A13403@opus.bloom.county \
--to=trini@kernel.crashing.org \
--cc=acahalan@cs.uml.edu \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=esr@thyrsus.com \
--cc=james.rich@m.cc.utah.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=nico@cam.org \
--cc=parisc-linux@parisc-linux.org \
--cc=willy@ldl.fc.hp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox