diff for duplicates of <20010420195004.A5510@flint.arm.linux.org.uk> diff --git a/a/1.txt b/N1/1.txt index 9d71a82..2abb319 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -3,3 +3,32 @@ On Fri, Apr 20, 2001 at 10:59:34AM -0400, Eric S. Raymond wrote: > 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 (rmk@arm.linux.org.uk) The developer of ARM Linux + http://www.arm.linux.org.uk/personal/aboutme.html diff --git a/a/content_digest b/N1/content_digest index 2f6b507..101db5f 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -17,6 +17,35 @@ "> All right then. I'm going to send you a bunch of dead-symbol cleanup\n" "> patches. I'll try to stay in the mainline code and out of the port\n" "> trees. Would you please do me the kindness of telling me which ones\n" - > can go in and which ones you think have to go through maintainers? + "> can go in and which ones you think have to go through maintainers?\n" + "\n" + ">From my point of view, I'd be happy if stuff that touched the ARM tree\n" + "directly was sent separately from the other architectures, and actually\n" + "was copied to me. I'm sure that the other architecture maintainers\n" + "feel the same way, but I'll let them comment separately.\n" + "\n" + "Why? Well:\n" + "\n" + "- Firstly, I can apply your patch directly to my tree without having\n" + " to bother about the effects in the other architecture trees. (hence\n" + " when I resync with Linus or Alan, I don't have to go around fixing\n" + " up rejects in other architecture trees).\n" + "\n" + "- Secondly, its very easy to miss stuff in the lkml hunk of email each\n" + " day when you have less than 4 hours to read it and think about it.\n" + " (note that architecture maintainers have to read mail from their\n" + " side which may not be on lkml, think about that, think about bug fixes,\n" + " possible impacts of fixes on other machines, etc etc). Therefore,\n" + " copying their email address registered in the MAINTAINER file means\n" + " that they should not overlook your patch.\n" + "\n" + "- I know that Alan does take lots of patches off lkml, but I'm not sure\n" + " what his criterion is for selecting them. In the case which started\n" + " this thread off, I'm always worried that your cleanup patch would make\n" + " it in, and then cause me problems later on.\n" + "\n" + "--\n" + "Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux\n" + http://www.arm.linux.org.uk/personal/aboutme.html -f291de8e879ea2f00a1a7327278564ccc0788202a44ad85616d0c64e66ceea7d +eae7bc837211738804ca8082775b06626e45a5e1078605c2d66110449d1a3d85
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.