Messages in this thread | | | Date | Fri, 8 Jun 2001 11:12:55 +0200 | From | Francois Romieu <> | Subject | Re: Configure.help i18n system |
| |
Andries.Brouwer@cwi.nl <Andries.Brouwer@cwi.nl> ecrit : [...] > (i) The kernel has high visibility, and work on the kernel > [even if only on the Documentation subdirectory] has high "prestige". > As a consequence, parts of the kernel tree are kept much better > up-to-date than documentation found elsewhere.
Why would quality be lowered if instead of trying and push a Configure.help patch to an already busy Linus, one should notify the maintainer ? Simply because it doesn't gain the same "prestige" to the author ? *big pain*
I don't forget your proc.5/bootparam.7 argument but it's not the same point imho.
[...] > (ii) So far, building a kernel involved getting a single tarball. > If the help for over a thousand configuration options is found > a hundred different places on the net, of which five are currently > unreachable, things get really cumbersome.
Not everybody reads a thousand configuration options entry. If I want a kernel tailored for a specific machine, I keep a .config somewhere, make oldconfig and so on. I don't read a Configure.help entry that hasn't changed for months. Documentation/Changes is enough. If I want to build the usual "does everything compile?" kernel, the Configure.help entry isn't that needed. If it's the first time I compile a kernel, $DISTRIBUTION could include the extra package somewhere. Outdated ? We aren't talking about people working with testing versions thus I doubt it's really a problem.
> The current system is not so bad.
Yes. However, the point of "Configure.help doesn't belong to core" makes sense (as long as it doesn't prevent compile).
-- Ueimor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |