Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
Grant Grundler <[EMAIL PROTECTED]>: > One might consider this a bug that hasn't happened yet - thanks Eric! Thank you very much for your cooperation. This is the third real problem that the CONFIG_ namespace audit has turned up, and a good example of the sort of thing I have been hoping to accomplish with it. -- http://www.tuxedo.org/~esr/">Eric S. Raymond (Those) who are trying to read the Second Amendment out of the Constitution by claiming it's not an individual right (are) courting disaster by encouraging others to use the same means to eliminate portions of the Constitution they don't like. -- Alan Dershowitz, Harvard Law School - 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
[EMAIL PROTECTED] said: > If it can't be mechanically verified that the symbol has a correct > reference pattern within the tree, then it's broken. That's a > definition. Here's an alternative definition: If the symbol has the letters 'F', 'I', 'S' and 'H' in it, in any order, then it's broken. That's also a definition. It's not a particularly useful one, but neither was yours. /me looks for a way to equate the original definition with the halting problem :) -- 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
"Eric S. Raymond" wrote:
> Here's what I have for you guys:
...
> CONFIG_DMB_TRAP: arch/parisc/kernel/sba_iommu.c
> CONFIG_FUNC_SIZE: arch/parisc/kernel/sba_iommu.c
>
> Would you please take these out of the CONFIG_ namespace? Changing the
> prefix to CONFIGURE would do nicely.
As willy noted, both mine. I'll remove or rename them rename them so
they aren't in the CONFIG_ name space. Probably s/CONFIG_/SBA_/ for
those two.
I'm going to submit a "wishlist" bug to our debian BTS
(bugs.parisc-linux.org) for "Data Memory Break Trap" support.
It's a damn good Hammer! :^)
(GDB will probably want to use this too)
I once had a working "Data Memory Break Trap" handler to catch other
parts of the kernel when they corrupted the IO Pdirs. Hooks in sba_ccio.c
helped mark which pages would trap and define which code was allowed to
touch the page. My implementation had issues and I never bothered to
re-implement as suggested by our parisc CPU god, John Marvin.
CONFIG_FUNC_SIZE is just a bad choice of name (asking for trouble).
One might consider this a bug that hasn't happened yet - thanks Eric!
#define CONFIG_FUNC_SIZE 4096 /* SBA configuration function reg set */
> CONFIG_KWDB: arch/parisc/Makefile arch/parisc/config.in arch/parisc/defconfig
>arch/parisc/kernel/entry.S arch/parisc/kernel/traps.c arch/parisc/mm/init.
> c
This ones actually mine too. It could be replaced with the SGI debugger
CONFIG option if/when that ever gets supported. The hooks will have to
be in the same place. I'm pretty sure now the HP KWBD team will never give me
permission to publish KWDB sources (they've had almost a year now).
I sorta almost had the damn thing working too...*sigh*.
Willy should do whatever he thinks is right in this case.
> CONFIG_PCI_LBA: arch/parisc/config.in arch/parisc/defconfig arch/parisc/kerne
> l/Makefile
...
> Looks like these need Configure.help entries.
That's mine too.
We've been lazy about documentation since the getting the code working
has been a higher priority. I think having them documented will be a
prerequisite to merging upstream (either to Alan Cox or Linus).
thanks,
grant
Grant Grundler
parisc-linux {PCI|IOMMU|SMP} hacker
+1.408.447.7253
-
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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
"Eric S. Raymond" wrote:
Here's what I have for you guys:
...
CONFIG_DMB_TRAP: arch/parisc/kernel/sba_iommu.c
CONFIG_FUNC_SIZE: arch/parisc/kernel/sba_iommu.c
Would you please take these out of the CONFIG_ namespace? Changing the
prefix to CONFIGURE would do nicely.
As willy noted, both mine. I'll remove or rename them rename them so
they aren't in the CONFIG_ name space. Probably s/CONFIG_/SBA_/ for
those two.
I'm going to submit a "wishlist" bug to our debian BTS
(bugs.parisc-linux.org) for "Data Memory Break Trap" support.
It's a damn good Hammer! :^)
(GDB will probably want to use this too)
I once had a working "Data Memory Break Trap" handler to catch other
parts of the kernel when they corrupted the IO Pdirs. Hooks in sba_ccio.c
helped mark which pages would trap and define which code was allowed to
touch the page. My implementation had issues and I never bothered to
re-implement as suggested by our parisc CPU god, John Marvin.
CONFIG_FUNC_SIZE is just a bad choice of name (asking for trouble).
One might consider this a bug that hasn't happened yet - thanks Eric!
#define CONFIG_FUNC_SIZE 4096 /* SBA configuration function reg set */
CONFIG_KWDB: arch/parisc/Makefile arch/parisc/config.in arch/parisc/defconfig
arch/parisc/kernel/entry.S arch/parisc/kernel/traps.c arch/parisc/mm/init.
c
This ones actually mine too. It could be replaced with the SGI debugger
CONFIG option if/when that ever gets supported. The hooks will have to
be in the same place. I'm pretty sure now the HP KWBD team will never give me
permission to publish KWDB sources (they've had almost a year now).
I sorta almost had the damn thing working too...*sigh*.
Willy should do whatever he thinks is right in this case.
CONFIG_PCI_LBA: arch/parisc/config.in arch/parisc/defconfig arch/parisc/kerne
l/Makefile
...
Looks like these need Configure.help entries.
That's mine too.
We've been lazy about documentation since the getting the code working
has been a higher priority. I think having them documented will be a
prerequisite to merging upstream (either to Alan Cox or Linus).
thanks,
grant
Grant Grundler
parisc-linux {PCI|IOMMU|SMP} hacker
+1.408.447.7253
-
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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
[EMAIL PROTECTED] said: If it can't be mechanically verified that the symbol has a correct reference pattern within the tree, then it's broken. That's a definition. Here's an alternative definition: If the symbol has the letters 'F', 'I', 'S' and 'H' in it, in any order, then it's broken. That's also a definition. It's not a particularly useful one, but neither was yours. /me looks for a way to equate the original definition with the halting problem :) -- 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
Grant Grundler [EMAIL PROTECTED]: One might consider this a bug that hasn't happened yet - thanks Eric! Thank you very much for your cooperation. This is the third real problem that the CONFIG_ namespace audit has turned up, and a good example of the sort of thing I have been hoping to accomplish with it. -- a href="http://www.tuxedo.org/~esr/"Eric S. Raymond/a (Those) who are trying to read the Second Amendment out of the Constitution by claiming it's not an individual right (are) courting disaster by encouraging others to use the same means to eliminate portions of the Constitution they don't like. -- Alan Dershowitz, Harvard Law School - 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
[Cc: trimmed] Russell King wrote: > [...] > > Generally it seems like diff needs to produce one more line of context, and > most of these problems will go away. Yes, there will still be the odd > problem, so then it becomes the "how much do you crank the setting" problem. > $ diff -6 ... will give 6 lines of context. patch will understand the output without any extra help. Cheers, Tom -- The Daemons lurk and are dumb. -- Emerson - 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
Alan Cox <[EMAIL PROTECTED]>: > > Even supposing that's so, a 36% rate of broken symbols is way too high. > > It argues that we need to do a thorough housecleaning at least once in > > order to get back to an acceptably low stable rate. > > Many of your 'broken' symbols arent. We have no idea what the real amount is If it can't be mechanically verified that the symbol has a correct reference pattern within the tree, then it's broken. That's a definition. The fact that it might become un-broken someday, by somebody's intention to merge in future code, is interesting but irrelevant to the fact that symbols broken in present time *mask bugs* in present time. I'm not being a compulsive neatnik -- that wouldn't be worth my time. What I'm trying to do is reduce the number of crevices in which bugs can hide. -- http://www.tuxedo.org/~esr/">Eric S. Raymond This would be the best of all possible worlds, if there were no religion in it. -- John Adams, in a letter to Thomas Jefferson. - 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
David Woodhouse <[EMAIL PROTECTED]>: > [EMAIL PROTECTED] said: > > Even supposing that's so, a 36% rate of broken symbols is way too > > high. It argues that we need to do a thorough housecleaning at least > > once in order to get back to an acceptably low stable rate. > > Accepted. Can we let the 2.4 "angry penguin"-enforced stabilising period > finish, and give the arch and subsystem maintainers a chance to finally > brave the wrath of Linus and submit their patches, before we attempt do to > it though? I guess so. We don't particularly have a choice, do we? :-) -- http://www.tuxedo.org/~esr/">Eric S. Raymond "Government is not reason, it is not eloquence, it is force; like fire, a troublesome servant and a fearful master. Never for a moment should it be left to irresponsible action." -- George Washington, in a speech of January 7, 1790 - 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
> Even supposing that's so, a 36% rate of broken symbols is way too high. > It argues that we need to do a thorough housecleaning at least once in > order to get back to an acceptably low stable rate. Many of your 'broken' symbols arent. We have no idea what the real amount is - 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
[EMAIL PROTECTED] said: > Even supposing that's so, a 36% rate of broken symbols is way too > high. It argues that we need to do a thorough housecleaning at least > once in order to get back to an acceptably low stable rate. Accepted. Can we let the 2.4 "angry penguin"-enforced stabilising period finish, and give the arch and subsystem maintainers a chance to finally brave the wrath of Linus and submit their patches, before we attempt do to it though? -- 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
David Woodhouse <[EMAIL PROTECTED]>: > I'd be very surprised if the number of false positives isn't fairly stable, > with new ones being introduced at a similar rate to the rate at which old > ones finally become correct. Even supposing that's so, a 36% rate of broken symbols is way too high. It argues that we need to do a thorough housecleaning at least once in order to get back to an acceptably low stable rate. -- http://www.tuxedo.org/~esr/">Eric S. Raymond The same applies for other kinds of long-lasting low-level pain. [...] The body's response to being jabbed, pierced, and cut is to produce endorphins. [...] So here's my programme for breaking that cycle of dependency on Windows: get left arm tattooed with dragon motif, buy a crate of Jamaican Hot! Pepper Sauce, get nipples pierced. With any luck that will produce enough endorphins to make Windows completely redundant, and I can then upgrade to Linux and get on with things. -- Pieter Hintjens - 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
[EMAIL PROTECTED] said: > Not good enough. In a year, the pile of false positives would get > high enough to make it too hard to spot real bugs like the Aironet > mismatch. The whole point of the cleanup is to be able to mechanize > the consistency checks so they require a minimum of human judgment. I'm not sure that's the case. The nature of the false positives is that they're generally _temporary_ aberrations, caused by the loss of synchronisation of various maintainers w.r.t submitting patches to Linus. I'd be very surprised if the number of false positives isn't fairly stable, with new ones being introduced at a similar rate to the rate at which old ones finally become correct. Might be interesting to check a few older kernels to see if this is true. Actually I might expect it to be roughly proportional to the number of separately-maintained bodies of code - so it'll grow over time, as the size of the Linux kernel grows. -- 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
David Woodhouse <[EMAIL PROTECTED]>: > > 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? > > By periodically publishing a list of the potentially-obsolete symbols as ESR > has done, and _not_ removing the ones which people speak up about. It's not > as if this is something which needs to be done more than about once a year. Not good enough. In a year, the pile of false positives would get high enough to make it too hard to spot real bugs like the Aironet mismatch. The whole point of the cleanup is to be able to mechanize the consistency checks so they require a minimum of human judgment. -- 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
[EMAIL PROTECTED] said: > 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. Maybe. But you tend to include the latest MTD code in your tree, for example, and hence the defconfigs have the new options in. Is it really worth your time to produce separate defconfigs without it before feeding your changes upstream? > 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? By periodically publishing a list of the potentially-obsolete symbols as ESR has done, and _not_ removing the ones which people speak up about. It's not as if this is something which needs to be done more than about once a year. -- 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
[EMAIL PROTECTED] said: > Have you tried mailing [EMAIL PROTECTED] and asking to be added? Yes. [EMAIL PROTECTED] said: > I'd be highly surprised if they said no to adding UML to the list if > you mailed them a request to update the page. Well, be surprised then. The reply from hpa was that that list was for processor ports. He did say that there might at some point in the future be a separate list (off the main page) of other things. Jeff - 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
On Fri, Apr 20, 2001 at 12:50:05PM -0400, Eric S. Raymond wrote: > Nicolas Pitre <[EMAIL PROTECTED]>: > > 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. Really, the above issue is down to the sub-architecture maintainers splitting up their patches into the "one feature, one bug" thing, rather than "one set of files" (which, incidentally I'm guilty of as well). That way, when stuff gets added, you get: 1. The C source changes for that item 2. The configure script stuff for that one item 3. The help text for that one item. Currently, stuff that comes to me appears mostly as "here's a configure update", "here's a PCMCIA update", etc. I'll pull out an instance from my patch tracking system (sorry, Philip, yours is the first one I found): Patch 413/1 (see http://www.arm.linux.org.uk/developer/patches/?id=413/1=patch) This patch adds the defconfig file for the CLPS7500 architecture, and it contains symbols such as: CONFIG_BLK_DEV_FLD7500 CONFIG_CLPS7500_FLASH Neither of these two drivers are currently in Linus' tree, or in fact my tree. Should I reject the patch? Should I accept it and edit these out, or what? > And now it has a cost, too. It makes finding real bugs more difficult. Well, if they get removed in Linus tree, then when I next sync, they'll get re-added, or maybe they won't. Then someone else will remove them, then they'll get re-added ad infinitum. This also touches on another issue - patch. I've had several times where I've sent Alan stuff, its gone up to Linus, I receive it back, and during the merge, patch does its stuff without complaining (because there is not enough context in the diff). Typically, this happens in the Configure.help file. Generally it seems like diff needs to produce one more line of context, and most of these problems will go away. Yes, there will still be the odd problem, so then it becomes the "how much do you crank the setting" problem. -- 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
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/ - 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
On Fri, Apr 20, 2001 at 10:59:34AM -0400, Eric S. Raymond wrote: > All right then. I'm going to send you a bunch of dead-symbol cleanup > patches. I'll try to stay in the mainline code and out of the port > trees. Would you please do me the kindness of telling me which ones > can go in and which ones you think have to go through maintainers? >From my point of view, I'd be happy if stuff that touched the ARM tree directly was sent separately from the other architectures, and actually was copied to me. I'm sure that the other architecture maintainers feel the same way, but I'll let them comment separately. Why? Well: - Firstly, I can apply your patch directly to my tree without having to bother about the effects in the other architecture trees. (hence when I resync with Linus or Alan, I don't have to go around fixing up rejects in other architecture trees). - Secondly, its very easy to miss stuff in the lkml hunk of email each day when you have less than 4 hours to read it and think about it. (note that architecture maintainers have to read mail from their side which may not be on lkml, think about that, think about bug fixes, possible impacts of fixes on other machines, etc etc). Therefore, copying their email address registered in the MAINTAINER file means that they should not overlook your patch. - I know that Alan does take lots of patches off lkml, but I'm not sure what his criterion is for selecting them. In the case which started this thread off, I'm always worried that your cleanup patch would make it in, and then cause me problems later on. -- 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
> "Jeff" == Jeff Dike <[EMAIL PROTECTED]> writes: Jeff> [EMAIL PROTECTED] said: >> http://www.kernel.org/ has a list of architecture websites. Also >> the CREDITS / MAINTAINERS files tend to list the people who are >> involved. Jeff> Except it's restricted to processor ports, which would leave you Jeff> not knowing about UML. I'd be highly surprised if they said no to adding UML to the list if you mailed them a request to update the page. 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
On Fri, Apr 20, 2001 at 02:00:00PM -0500, Jeff Dike wrote: > [EMAIL PROTECTED] said: > > http://www.kernel.org/ has a list of architecture websites. Also the > > CREDITS / MAINTAINERS files tend to list the people who are involved. > > Except it's restricted to processor ports, which would leave you not knowing > about UML. Have you tried mailing [EMAIL PROTECTED] and asking to be added? -- Revolutions do not require corporate support. - 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
On Fri, Apr 20, 2001 at 12:35:12PM -0400, Nicolas Pitre wrote: > There is kind of a ridiculous situation here where people want to withhold > their own changes in their own trees for all good reasons until it is mature > and stable enough to be fed upstream in the appropriate way, while insisting > for Linus' tree to remain incomplete and inconsistent. And we're not > talking about deep architectural changes here -- only about configure > symbols and help text. The answer is simple, noise. > 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. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
[EMAIL PROTECTED] said: > http://www.kernel.org/ has a list of architecture websites. Also the > CREDITS / MAINTAINERS files tend to list the people who are involved. Except it's restricted to processor ports, which would leave you not knowing about UML. Jeff - 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
Nicolas Pitre <[EMAIL PROTECTED]>: > 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. And now it has a cost, too. It makes finding real bugs more difficult. -- http://www.tuxedo.org/~esr/">Eric S. Raymond Every election is a sort of advance auction sale of stolen goods. -- H.L. Mencken - 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
Bob McElrath wrote: > > Jeff Garzik [[EMAIL PROTECTED]] wrote: > > Tom Rini wrote: > > > Which does boil down to having to work with trees other than Linus or > > > Alans. Remember, the official tree is not always the up-to-date tree, > > > or in the case of other arches, the most relevant tree. > > > > Yep. You could even look at Linus as simply the x86 port maintainer :) > > > > Except for alpha and x86, AFAIK, most people wind up going through > > arch-specific channels to get their kernels... > > This may be a dumb question, but is there some place where the arch > maintainers are listed? Where the arch-specific trees are kept? Where > would I go to get the latest set of relevant patches for alpha? As I noted in the e-mail to which you replied, there is no separate alpha tree nor arch-specific channel for alpha kernels. Generally fixes to the Alpha tree appear quickly and get merged quickly, and the tree stays in sync quite well. Watch linux-kernel or Alan Cox's patchkit for Alpha fixes that may be in transmit to Linus. There are of course RedHat's alpha distro, and various mailing lists on http://www.alphalinux.org/ -- Jeff Garzik | The difference between America and England is that Building 1024| the English think 100 miles is a long distance and MandrakeSoft | the Americans think 100 years is a long time. | (random fortune) - 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
On Fri, Apr 20, 2001 at 11:15:12AM -0500, Bob McElrath wrote: > This may be a dumb question, but is there some place where the arch > maintainers are listed? Where the arch-specific trees are kept? Where > would I go to get the latest set of relevant patches for alpha? http://www.kernel.org/ has a list of architecture websites. Also the CREDITS / MAINTAINERS files tend to list the people who are involved. -- Revolutions do not require corporate support. - 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
Jeff Garzik [[EMAIL PROTECTED]] wrote: > Tom Rini wrote: > > Which does boil down to having to work with trees other than Linus or > > Alans. Remember, the official tree is not always the up-to-date tree, > > or in the case of other arches, the most relevant tree. > > Yep. You could even look at Linus as simply the x86 port maintainer :) > > Except for alpha and x86, AFAIK, most people wind up going through > arch-specific channels to get their kernels... This may be a dumb question, but is there some place where the arch maintainers are listed? Where the arch-specific trees are kept? Where would I go to get the latest set of relevant patches for alpha? Grepping the Documentation/ directory for "alpha" I see nothing relevant. IMHO this should all be listend in one place. Maybe Documentation/Arch-Maintainers.txt. Cheers, -- Bob Bob McElrath ([EMAIL PROTECTED]) Univ. of Wisconsin at Madison, Department of Physics PGP signature
Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
Tom Rini wrote: > Which does boil down to having to work with trees other than Linus or > Alans. Remember, the official tree is not always the up-to-date tree, > or in the case of other arches, the most relevant tree. Yep. You could even look at Linus as simply the x86 port maintainer :) Except for alpha and x86, AFAIK, most people wind up going through arch-specific channels to get their kernels... -- Jeff Garzik | The difference between America and England is that Building 1024| the English think 100 miles is a long distance and MandrakeSoft | the Americans think 100 years is a long time. | (random fortune) - 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
On Fri, Apr 20, 2001 at 10:59:34AM -0400, Eric S. Raymond wrote: > Alan Cox <[EMAIL PROTECTED]>: > > > well, though. One is the kind I'm bumping into right now, where > > > somebody legitimately needs to make small (almost trivial) changes > > > scattered all through the tree. > > > > Yep. But such changes are rare. Or should be. > > Knowing that doesn't help me much, since I'm trying to fix up a global > namespace that touches everybody :-(. Which does boil down to having to work with trees other than Linus or Alans. Remember, the official tree is not always the up-to-date tree, or in the case of other arches, the most relevant tree. But if you send something off to a maintainer, there's a good chance (if they're still active) they'll do what you ask, and it'll get to Linus/Alan the next time they sync. As long as the problem gets fixed, it shouldn't be as important if it's fixed in everyones tree right now, or in a release or two. If it's some sort of huge bug it just might get fixed sooner. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
Alan Cox <[EMAIL PROTECTED]>: > > well, though. One is the kind I'm bumping into right now, where > > somebody legitimately needs to make small (almost trivial) changes > > scattered all through the tree. > > Yep. But such changes are rare. Or should be. Knowing that doesn't help me much, since I'm trying to fix up a global namespace that touches everybody :-(. > If I get patches for stuff that doesnt seem to have a maintainer I > apply them. On the odd occasion a scream is heard in the distance > it means I now know there is an active maintainer. All right then. I'm going to send you a bunch of dead-symbol cleanup patches. I'll try to stay in the mainline code and out of the port trees. Would you please do me the kindness of telling me which ones can go in and which ones you think have to go through maintainers? You should have received one such patch already, fixes for two documentation files. -- http://www.tuxedo.org/~esr/">Eric S. Raymond Sometimes the law defends plunder and participates in it. Sometimes the law places the whole apparatus of judges, police, prisons and gendarmes at the service of the plunderers, and treats the victim -- when he defends himself -- as a criminal. -- Frederic Bastiat, "The Law" - 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
> I'll continue asking stupid questions, then. Like, under this system how > can either you or the port maintainers maintain a good representation of > how far out of sync they are with the main tree? diff and read the output. [bizzare sociopolitical mumble deleted] > well, though. One is the kind I'm bumping into right now, where > somebody legitimately needs to make small (almost trivial) changes > scattered all through the tree. Yep. But such changes are rare. Or should be. > Another is the case where a piece of code that needs to be changed doesn't > have an active maintainer for a third party like me to go to. > What's the neighborly way to deal with these? If I get patches for stuff that doesnt seem to have a maintainer I apply them. On the odd occasion a scream is heard in the distance it means I now know there is an active maintainer. - 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
Alan Cox <[EMAIL PROTECTED]>:
> People send batches of small fixes to Linus or to me. So for example
> the S/390 folks send me things like 'fix the mm layer to match the
> changes in 2.4.3' and 'Update the DASD storage driver'. Each of
> which fixes one thing or one set of things and is easy to check on
> its own
I'll continue asking stupid questions, then. Like, under this system how
can either you or the port maintainers maintain a good representation of
how far out of sync they are with the main tree?
The implied workflow (developers in general, up to port maintainers,
up to you and Linus) makes both technological and sociological sense.
It kind of reminds me of Anglo-Norman feudalism post-1066 ("No lord
without land, no land without a lord.").
There are a couple of funny edge cases that it doesn't seem to handle
well, though. One is the kind I'm bumping into right now, where
somebody legitimately needs to make small (almost trivial) changes
scattered all through the tree.
Another is the case where a piece of code that needs to be changed doesn't
have an active maintainer for a third party like me to go to.
What's the neighborly way to deal with these?
--
http://www.tuxedo.org/~esr/">Eric S. Raymond
"The best we can hope for concerning the people at large is that they be
properly armed."
-- Alexander Hamilton, The Federalist Papers at 184-188
-
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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
> OK, so maybe I'm being stupid. But the implication of this talk of separate > port trees and architecture merges is that these guys periodically send big > resync patches to you and Linus. > > If that's not what's going on, what is? People send batches of small fixes to Linus or to me. So for example the S/390 folks send me things like 'fix the mm layer to match the changes in 2.4.3' and 'Update the DASD storage driver'. Each of which fixes one thing or one set of things and is easy to check on its own - 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
> Alan Cox <[EMAIL PROTECTED]>: > > I have for one. Its definitely the wrong approach to bomb Linus with patches > > when doing the merge of an architecture. All the architecture folk with in > > their own trees for good reason. > > On the other hand, Linus has objected to the One-Big-Patch approach in > the past with respect to things like the networking and VM code. How > are people to know what the right thing is? Who said anything about one big patch ? Just because you have a lot of differences doesnt mean you send Linus one giant splat of code. I don't send Linus -ac for example. 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
Alan Cox <[EMAIL PROTECTED]>: > > Alan Cox <[EMAIL PROTECTED]>: > > > I have for one. Its definitely the wrong approach to bomb Linus > > > with patches when doing the merge of an architecture. All the > > > architecture folk with in their own trees for good reason. > > > > On the other hand, Linus has objected to the One-Big-Patch approach in > > the past with respect to things like the networking and VM code. How > > are people to know what the right thing is? > > Who said anything about one big patch ? Just because you have a lot > of differences doesnt mean you send Linus one giant splat of code. I > don't send Linus -ac for example. OK, so maybe I'm being stupid. But the implication of this talk of separate port trees and architecture merges is that these guys periodically send big resync patches to you and Linus. If that's not what's going on, what is? -- 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
Alan Cox <[EMAIL PROTECTED]>: > I have for one. Its definitely the wrong approach to bomb Linus with patches > when doing the merge of an architecture. All the architecture folk with in > their own trees for good reason. On the other hand, Linus has objected to the One-Big-Patch approach in the past with respect to things like the networking and VM code. How are people to know what the right thing is? -- http://www.tuxedo.org/~esr/">Eric S. Raymond Love your country, but never trust its government. -- Robert A. Heinlein. - 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
> > we sent him every single one of those patches individually. and we'd > > go insane trying to keep up with what he'd taken and what he'd dropped. > > > > until you've actually tried doing this, please don't attempt to criticise. > > Have _you_ tried? If I recall correctly, Linus spoke out against the I have for one. Its definitely the wrong approach to bomb Linus with patches when doing the merge of an architecture. All the architecture folk with in their own trees for good reason. Once the code is in a fit state to merge (ie actually works well with the new 2.4.x stuff and 2.4.x core stops shifting around) then the merge can get done piece by piece. - 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
> What is the right procedure for doing changes like this? Is "don't > touch that tree" a permanent condition, or am I going to get a chance > to clean up the global CONFIG_ namespace after your next merge-down? Feeding arch related stuff to the architecture maintainers. > That's the main thing I'm after right now -- I want to cut down on > the false positives in my orphaned-symbol reports so that the actual > bugs will stand out. Teach it to read a 'symbolstoignore' file. Part of the problem you are hitting right now is that most architectures are not yet fully in sync with 2.4 nor likely to all be for another few iterations. - 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
Alan Cox <[EMAIL PROTECTED]>: > > What is the right procedure for doing changes like this? Is "don't > > touch that tree" a permanent condition, or am I going to get a chance > > to clean up the global CONFIG_ namespace after your next merge-down? > > Feeding arch related stuff to the architecture maintainers. I shall attempt it. > > That's the main thing I'm after right now -- I want to cut down on > > the false positives in my orphaned-symbol reports so that the actual > > bugs will stand out. > > Teach it to read a 'symbolstoignore' file. Someone else has already pointed out that this is not a solution that will scale well. It would substitute a continuing management headache for the cleanup that's really needed. In fact I'm reluctant to do this even for cases where it's clearly legitimate (CONFIG_BOOM, CONFIG_BOGUS :-)) partly because later on it might provide an excuse for people not to do the cleanup. > Part of the problem you are hitting right now is that most > architectures are not yet fully in sync with 2.4 nor likely to all > be for another few iterations. Understood. I'll do what I can in the architecture-independent code, then. -- http://www.tuxedo.org/~esr/">Eric S. Raymond "Boys who own legal firearms have much lower rates of delinquency and drug use and are even slightly less delinquent than nonowners of guns." -- U.S. Department of Justice, National Institute of Justice, Office of Juvenile Justice and Delinquency Prevention, NCJ-143454, "Urban Delinquency and Substance Abuse," August 1995. - 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
Alan Cox [EMAIL PROTECTED]: What is the right procedure for doing changes like this? Is "don't touch that tree" a permanent condition, or am I going to get a chance to clean up the global CONFIG_ namespace after your next merge-down? Feeding arch related stuff to the architecture maintainers. I shall attempt it. That's the main thing I'm after right now -- I want to cut down on the false positives in my orphaned-symbol reports so that the actual bugs will stand out. Teach it to read a 'symbolstoignore' file. Someone else has already pointed out that this is not a solution that will scale well. It would substitute a continuing management headache for the cleanup that's really needed. In fact I'm reluctant to do this even for cases where it's clearly legitimate (CONFIG_BOOM, CONFIG_BOGUS :-)) partly because later on it might provide an excuse for people not to do the cleanup. Part of the problem you are hitting right now is that most architectures are not yet fully in sync with 2.4 nor likely to all be for another few iterations. Understood. I'll do what I can in the architecture-independent code, then. -- a href="http://www.tuxedo.org/~esr/"Eric S. Raymond/a "Boys who own legal firearms have much lower rates of delinquency and drug use and are even slightly less delinquent than nonowners of guns." -- U.S. Department of Justice, National Institute of Justice, Office of Juvenile Justice and Delinquency Prevention, NCJ-143454, "Urban Delinquency and Substance Abuse," August 1995. - 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
What is the right procedure for doing changes like this? Is "don't touch that tree" a permanent condition, or am I going to get a chance to clean up the global CONFIG_ namespace after your next merge-down? Feeding arch related stuff to the architecture maintainers. That's the main thing I'm after right now -- I want to cut down on the false positives in my orphaned-symbol reports so that the actual bugs will stand out. Teach it to read a 'symbolstoignore' file. Part of the problem you are hitting right now is that most architectures are not yet fully in sync with 2.4 nor likely to all be for another few iterations. - 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
we sent him every single one of those patches individually. and we'd go insane trying to keep up with what he'd taken and what he'd dropped. until you've actually tried doing this, please don't attempt to criticise. Have _you_ tried? If I recall correctly, Linus spoke out against the I have for one. Its definitely the wrong approach to bomb Linus with patches when doing the merge of an architecture. All the architecture folk with in their own trees for good reason. Once the code is in a fit state to merge (ie actually works well with the new 2.4.x stuff and 2.4.x core stops shifting around) then the merge can get done piece by piece. - 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
Alan Cox [EMAIL PROTECTED]: I have for one. Its definitely the wrong approach to bomb Linus with patches when doing the merge of an architecture. All the architecture folk with in their own trees for good reason. On the other hand, Linus has objected to the One-Big-Patch approach in the past with respect to things like the networking and VM code. How are people to know what the right thing is? -- a href="http://www.tuxedo.org/~esr/"Eric S. Raymond/a Love your country, but never trust its government. -- Robert A. Heinlein. - 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
Alan Cox [EMAIL PROTECTED]: Alan Cox [EMAIL PROTECTED]: I have for one. Its definitely the wrong approach to bomb Linus with patches when doing the merge of an architecture. All the architecture folk with in their own trees for good reason. On the other hand, Linus has objected to the One-Big-Patch approach in the past with respect to things like the networking and VM code. How are people to know what the right thing is? Who said anything about one big patch ? Just because you have a lot of differences doesnt mean you send Linus one giant splat of code. I don't send Linus -ac for example. OK, so maybe I'm being stupid. But the implication of this talk of separate port trees and architecture merges is that these guys periodically send big resync patches to you and Linus. If that's not what's going on, what is? -- 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
Alan Cox [EMAIL PROTECTED]: I have for one. Its definitely the wrong approach to bomb Linus with patches when doing the merge of an architecture. All the architecture folk with in their own trees for good reason. On the other hand, Linus has objected to the One-Big-Patch approach in the past with respect to things like the networking and VM code. How are people to know what the right thing is? Who said anything about one big patch ? Just because you have a lot of differences doesnt mean you send Linus one giant splat of code. I don't send Linus -ac for example. 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
OK, so maybe I'm being stupid. But the implication of this talk of separate port trees and architecture merges is that these guys periodically send big resync patches to you and Linus. If that's not what's going on, what is? People send batches of small fixes to Linus or to me. So for example the S/390 folks send me things like 'fix the mm layer to match the changes in 2.4.3' and 'Update the DASD storage driver'. Each of which fixes one thing or one set of things and is easy to check on its own - 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
Alan Cox [EMAIL PROTECTED]:
People send batches of small fixes to Linus or to me. So for example
the S/390 folks send me things like 'fix the mm layer to match the
changes in 2.4.3' and 'Update the DASD storage driver'. Each of
which fixes one thing or one set of things and is easy to check on
its own
I'll continue asking stupid questions, then. Like, under this system how
can either you or the port maintainers maintain a good representation of
how far out of sync they are with the main tree?
The implied workflow (developers in general, up to port maintainers,
up to you and Linus) makes both technological and sociological sense.
It kind of reminds me of Anglo-Norman feudalism post-1066 ("No lord
without land, no land without a lord.").
There are a couple of funny edge cases that it doesn't seem to handle
well, though. One is the kind I'm bumping into right now, where
somebody legitimately needs to make small (almost trivial) changes
scattered all through the tree.
Another is the case where a piece of code that needs to be changed doesn't
have an active maintainer for a third party like me to go to.
What's the neighborly way to deal with these?
--
a href="http://www.tuxedo.org/~esr/"Eric S. Raymond/a
"The best we can hope for concerning the people at large is that they be
properly armed."
-- Alexander Hamilton, The Federalist Papers at 184-188
-
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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
I'll continue asking stupid questions, then. Like, under this system how can either you or the port maintainers maintain a good representation of how far out of sync they are with the main tree? diff and read the output. [bizzare sociopolitical mumble deleted] well, though. One is the kind I'm bumping into right now, where somebody legitimately needs to make small (almost trivial) changes scattered all through the tree. Yep. But such changes are rare. Or should be. Another is the case where a piece of code that needs to be changed doesn't have an active maintainer for a third party like me to go to. What's the neighborly way to deal with these? If I get patches for stuff that doesnt seem to have a maintainer I apply them. On the odd occasion a scream is heard in the distance it means I now know there is an active maintainer. - 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
Alan Cox [EMAIL PROTECTED]: well, though. One is the kind I'm bumping into right now, where somebody legitimately needs to make small (almost trivial) changes scattered all through the tree. Yep. But such changes are rare. Or should be. Knowing that doesn't help me much, since I'm trying to fix up a global namespace that touches everybody :-(. If I get patches for stuff that doesnt seem to have a maintainer I apply them. On the odd occasion a scream is heard in the distance it means I now know there is an active maintainer. All right then. I'm going to send you a bunch of dead-symbol cleanup patches. I'll try to stay in the mainline code and out of the port trees. Would you please do me the kindness of telling me which ones can go in and which ones you think have to go through maintainers? You should have received one such patch already, fixes for two documentation files. -- a href="http://www.tuxedo.org/~esr/"Eric S. Raymond/a Sometimes the law defends plunder and participates in it. Sometimes the law places the whole apparatus of judges, police, prisons and gendarmes at the service of the plunderers, and treats the victim -- when he defends himself -- as a criminal. -- Frederic Bastiat, "The Law" - 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
On Fri, Apr 20, 2001 at 10:59:34AM -0400, Eric S. Raymond wrote: Alan Cox [EMAIL PROTECTED]: well, though. One is the kind I'm bumping into right now, where somebody legitimately needs to make small (almost trivial) changes scattered all through the tree. Yep. But such changes are rare. Or should be. Knowing that doesn't help me much, since I'm trying to fix up a global namespace that touches everybody :-(. Which does boil down to having to work with trees other than Linus or Alans. Remember, the official tree is not always the up-to-date tree, or in the case of other arches, the most relevant tree. But if you send something off to a maintainer, there's a good chance (if they're still active) they'll do what you ask, and it'll get to Linus/Alan the next time they sync. As long as the problem gets fixed, it shouldn't be as important if it's fixed in everyones tree right now, or in a release or two. If it's some sort of huge bug it just might get fixed sooner. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
Tom Rini wrote: Which does boil down to having to work with trees other than Linus or Alans. Remember, the official tree is not always the up-to-date tree, or in the case of other arches, the most relevant tree. Yep. You could even look at Linus as simply the x86 port maintainer :) Except for alpha and x86, AFAIK, most people wind up going through arch-specific channels to get their kernels... -- Jeff Garzik | The difference between America and England is that Building 1024| the English think 100 miles is a long distance and MandrakeSoft | the Americans think 100 years is a long time. | (random fortune) - 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
Jeff Garzik [[EMAIL PROTECTED]] wrote: Tom Rini wrote: Which does boil down to having to work with trees other than Linus or Alans. Remember, the official tree is not always the up-to-date tree, or in the case of other arches, the most relevant tree. Yep. You could even look at Linus as simply the x86 port maintainer :) Except for alpha and x86, AFAIK, most people wind up going through arch-specific channels to get their kernels... This may be a dumb question, but is there some place where the arch maintainers are listed? Where the arch-specific trees are kept? Where would I go to get the latest set of relevant patches for alpha? Grepping the Documentation/ directory for "alpha" I see nothing relevant. IMHO this should all be listend in one place. Maybe Documentation/Arch-Maintainers.txt. Cheers, -- Bob Bob McElrath ([EMAIL PROTECTED]) Univ. of Wisconsin at Madison, Department of Physics PGP signature
Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
On Fri, Apr 20, 2001 at 11:15:12AM -0500, Bob McElrath wrote: This may be a dumb question, but is there some place where the arch maintainers are listed? Where the arch-specific trees are kept? Where would I go to get the latest set of relevant patches for alpha? http://www.kernel.org/ has a list of architecture websites. Also the CREDITS / MAINTAINERS files tend to list the people who are involved. -- Revolutions do not require corporate support. - 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
Bob McElrath wrote: Jeff Garzik [[EMAIL PROTECTED]] wrote: Tom Rini wrote: Which does boil down to having to work with trees other than Linus or Alans. Remember, the official tree is not always the up-to-date tree, or in the case of other arches, the most relevant tree. Yep. You could even look at Linus as simply the x86 port maintainer :) Except for alpha and x86, AFAIK, most people wind up going through arch-specific channels to get their kernels... This may be a dumb question, but is there some place where the arch maintainers are listed? Where the arch-specific trees are kept? Where would I go to get the latest set of relevant patches for alpha? As I noted in the e-mail to which you replied, there is no separate alpha tree nor arch-specific channel for alpha kernels. Generally fixes to the Alpha tree appear quickly and get merged quickly, and the tree stays in sync quite well. Watch linux-kernel or Alan Cox's patchkit for Alpha fixes that may be in transmit to Linus. There are of course RedHat's alpha distro, and various mailing lists on http://www.alphalinux.org/ -- Jeff Garzik | The difference between America and England is that Building 1024| the English think 100 miles is a long distance and MandrakeSoft | the Americans think 100 years is a long time. | (random fortune) - 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
On Fri, Apr 20, 2001 at 12:35:12PM -0400, Nicolas Pitre wrote: There is kind of a ridiculous situation here where people want to withhold their own changes in their own trees for all good reasons until it is mature and stable enough to be fed upstream in the appropriate way, while insisting for Linus' tree to remain incomplete and inconsistent. And we're not talking about deep architectural changes here -- only about configure symbols and help text. The answer is simple, noise. 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. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
On Fri, Apr 20, 2001 at 02:00:00PM -0500, Jeff Dike wrote: [EMAIL PROTECTED] said: http://www.kernel.org/ has a list of architecture websites. Also the CREDITS / MAINTAINERS files tend to list the people who are involved. Except it's restricted to processor ports, which would leave you not knowing about UML. Have you tried mailing [EMAIL PROTECTED] and asking to be added? -- Revolutions do not require corporate support. - 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
"Jeff" == Jeff Dike [EMAIL PROTECTED] writes: Jeff [EMAIL PROTECTED] said: http://www.kernel.org/ has a list of architecture websites. Also the CREDITS / MAINTAINERS files tend to list the people who are involved. Jeff Except it's restricted to processor ports, which would leave you Jeff not knowing about UML. I'd be highly surprised if they said no to adding UML to the list if you mailed them a request to update the page. 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
On Fri, Apr 20, 2001 at 10:59:34AM -0400, Eric S. Raymond wrote: All right then. I'm going to send you a bunch of dead-symbol cleanup patches. I'll try to stay in the mainline code and out of the port trees. Would you please do me the kindness of telling me which ones can go in and which ones you think have to go through maintainers? From my point of view, I'd be happy if stuff that touched the ARM tree directly was sent separately from the other architectures, and actually was copied to me. I'm sure that the other architecture maintainers feel the same way, but I'll let them comment separately. Why? Well: - Firstly, I can apply your patch directly to my tree without having to bother about the effects in the other architecture trees. (hence when I resync with Linus or Alan, I don't have to go around fixing up rejects in other architecture trees). - Secondly, its very easy to miss stuff in the lkml hunk of email each day when you have less than 4 hours to read it and think about it. (note that architecture maintainers have to read mail from their side which may not be on lkml, think about that, think about bug fixes, possible impacts of fixes on other machines, etc etc). Therefore, copying their email address registered in the MAINTAINER file means that they should not overlook your patch. - I know that Alan does take lots of patches off lkml, but I'm not sure what his criterion is for selecting them. In the case which started this thread off, I'm always worried that your cleanup patch would make it in, and then cause me problems later on. -- 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
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/ - 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
On Fri, Apr 20, 2001 at 12:50:05PM -0400, Eric S. Raymond wrote: Nicolas Pitre [EMAIL PROTECTED]: 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. Really, the above issue is down to the sub-architecture maintainers splitting up their patches into the "one feature, one bug" thing, rather than "one set of files" (which, incidentally I'm guilty of as well). That way, when stuff gets added, you get: 1. The C source changes for that item 2. The configure script stuff for that one item 3. The help text for that one item. Currently, stuff that comes to me appears mostly as "here's a configure update", "here's a PCMCIA update", etc. I'll pull out an instance from my patch tracking system (sorry, Philip, yours is the first one I found): Patch 413/1 (see http://www.arm.linux.org.uk/developer/patches/?id=413/1mode=patch) This patch adds the defconfig file for the CLPS7500 architecture, and it contains symbols such as: CONFIG_BLK_DEV_FLD7500 CONFIG_CLPS7500_FLASH Neither of these two drivers are currently in Linus' tree, or in fact my tree. Should I reject the patch? Should I accept it and edit these out, or what? And now it has a cost, too. It makes finding real bugs more difficult. Well, if they get removed in Linus tree, then when I next sync, they'll get re-added, or maybe they won't. Then someone else will remove them, then they'll get re-added ad infinitum. This also touches on another issue - patch. I've had several times where I've sent Alan stuff, its gone up to Linus, I receive it back, and during the merge, patch does its stuff without complaining (because there is not enough context in the diff). Typically, this happens in the Configure.help file. Generally it seems like diff needs to produce one more line of context, and most of these problems will go away. Yes, there will still be the odd problem, so then it becomes the "how much do you crank the setting" problem. -- 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
[EMAIL PROTECTED] said: Have you tried mailing [EMAIL PROTECTED] and asking to be added? Yes. [EMAIL PROTECTED] said: I'd be highly surprised if they said no to adding UML to the list if you mailed them a request to update the page. Well, be surprised then. The reply from hpa was that that list was for processor ports. He did say that there might at some point in the future be a separate list (off the main page) of other things. Jeff - 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
[EMAIL PROTECTED] said: 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. Maybe. But you tend to include the latest MTD code in your tree, for example, and hence the defconfigs have the new options in. Is it really worth your time to produce separate defconfigs without it before feeding your changes upstream? 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? By periodically publishing a list of the potentially-obsolete symbols as ESR has done, and _not_ removing the ones which people speak up about. It's not as if this is something which needs to be done more than about once a year. -- 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
David Woodhouse [EMAIL PROTECTED]: 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? By periodically publishing a list of the potentially-obsolete symbols as ESR has done, and _not_ removing the ones which people speak up about. It's not as if this is something which needs to be done more than about once a year. Not good enough. In a year, the pile of false positives would get high enough to make it too hard to spot real bugs like the Aironet mismatch. The whole point of the cleanup is to be able to mechanize the consistency checks so they require a minimum of human judgment. -- 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
[EMAIL PROTECTED] said: Not good enough. In a year, the pile of false positives would get high enough to make it too hard to spot real bugs like the Aironet mismatch. The whole point of the cleanup is to be able to mechanize the consistency checks so they require a minimum of human judgment. I'm not sure that's the case. The nature of the false positives is that they're generally _temporary_ aberrations, caused by the loss of synchronisation of various maintainers w.r.t submitting patches to Linus. I'd be very surprised if the number of false positives isn't fairly stable, with new ones being introduced at a similar rate to the rate at which old ones finally become correct. Might be interesting to check a few older kernels to see if this is true. Actually I might expect it to be roughly proportional to the number of separately-maintained bodies of code - so it'll grow over time, as the size of the Linux kernel grows. -- 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
David Woodhouse [EMAIL PROTECTED]: I'd be very surprised if the number of false positives isn't fairly stable, with new ones being introduced at a similar rate to the rate at which old ones finally become correct. Even supposing that's so, a 36% rate of broken symbols is way too high. It argues that we need to do a thorough housecleaning at least once in order to get back to an acceptably low stable rate. -- a href="http://www.tuxedo.org/~esr/"Eric S. Raymond/a The same applies for other kinds of long-lasting low-level pain. [...] The body's response to being jabbed, pierced, and cut is to produce endorphins. [...] So here's my programme for breaking that cycle of dependency on Windows: get left arm tattooed with dragon motif, buy a crate of Jamaican Hot! Pepper Sauce, get nipples pierced. With any luck that will produce enough endorphins to make Windows completely redundant, and I can then upgrade to Linux and get on with things. -- Pieter Hintjens - 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
[EMAIL PROTECTED] said: Even supposing that's so, a 36% rate of broken symbols is way too high. It argues that we need to do a thorough housecleaning at least once in order to get back to an acceptably low stable rate. Accepted. Can we let the 2.4 "angry penguin"-enforced stabilising period finish, and give the arch and subsystem maintainers a chance to finally brave the wrath of Linus and submit their patches, before we attempt do to it though? -- 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
Even supposing that's so, a 36% rate of broken symbols is way too high. It argues that we need to do a thorough housecleaning at least once in order to get back to an acceptably low stable rate. Many of your 'broken' symbols arent. We have no idea what the real amount is - 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
David Woodhouse [EMAIL PROTECTED]: [EMAIL PROTECTED] said: Even supposing that's so, a 36% rate of broken symbols is way too high. It argues that we need to do a thorough housecleaning at least once in order to get back to an acceptably low stable rate. Accepted. Can we let the 2.4 "angry penguin"-enforced stabilising period finish, and give the arch and subsystem maintainers a chance to finally brave the wrath of Linus and submit their patches, before we attempt do to it though? I guess so. We don't particularly have a choice, do we? :-) -- a href="http://www.tuxedo.org/~esr/"Eric S. Raymond/a "Government is not reason, it is not eloquence, it is force; like fire, a troublesome servant and a fearful master. Never for a moment should it be left to irresponsible action." -- George Washington, in a speech of January 7, 1790 - 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
Alan Cox [EMAIL PROTECTED]: Even supposing that's so, a 36% rate of broken symbols is way too high. It argues that we need to do a thorough housecleaning at least once in order to get back to an acceptably low stable rate. Many of your 'broken' symbols arent. We have no idea what the real amount is If it can't be mechanically verified that the symbol has a correct reference pattern within the tree, then it's broken. That's a definition. The fact that it might become un-broken someday, by somebody's intention to merge in future code, is interesting but irrelevant to the fact that symbols broken in present time *mask bugs* in present time. I'm not being a compulsive neatnik -- that wouldn't be worth my time. What I'm trying to do is reduce the number of crevices in which bugs can hide. -- a href="http://www.tuxedo.org/~esr/"Eric S. Raymond/a This would be the best of all possible worlds, if there were no religion in it. -- John Adams, in a letter to Thomas Jefferson. - 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
[Cc: trimmed] Russell King wrote: [...] Generally it seems like diff needs to produce one more line of context, and most of these problems will go away. Yes, there will still be the odd problem, so then it becomes the "how much do you crank the setting" problem. $ diff -6 ... will give 6 lines of context. patch will understand the output without any extra help. Cheers, Tom -- The Daemons lurk and are dumb. -- Emerson - 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/
