diff for duplicates of <20080508105905.3209c659@hyperion.delvare> diff --git a/a/1.txt b/N1/1.txt index 4310d35..836e904 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -35,79 +35,3 @@ value you add, not how important the change is in the big picture. > This is mostly habitual -- this is what the GNU Coding Standard specifies > for comments and which is enforced for GNU software which I have dealt a > lot with. - -From Documentation/CodingStyle: - -"First off, I'd suggest printing out a copy of the GNU coding standards, -and NOT read it. Burn them, it's a great symbolic gesture." - -I'm not going to tell how bad I think the GNU coding standards are, the -point here is that we don't follow them at all, so whatever they say is -totally irrelevant. Read Documentation/CodingStyle, it describes what -we do. Also make sure that you run your patches through -scripts/checkpatch.pl. The rest is up to you, but in general, when -modifying existing code, you want to stick to what the surrounding code -looks like. - -> I think the idea is it improves readability and I tend to -> agree. The same goes for using a capital at the beginning and a full stop -> at the end of sentences in comments -- it improves readability and -> (together with a good style of code itself) makes the result look more -> professional. Certainly well-formatted code is easier to comprehend for -> someone looking at it for the first time. -> -> I do not insist on the extraneous space if you have a strong opinion -> against though. - -I do insist ;) Admittedly, double spaces at end of comments are used in -some places in the kernel tree (I had never seen that before), but they -are still outnumbered by single-space ending comments, 50 to 1. Do -what you want in the drivers your create or maintain, but please don't -change existing comments, especially not in the middle of functional -changes. - -> > I'm not sure how you intend to push these changes upstream. I would -> > take a patch only touching drivers/i2c/busses/i2c-sibyte.c in my i2c -> > tree, however a patch also touching arch code, must be handled be the -> > maintainer for that architecture or platform. -> -> Andrew has spoken (thank you, Andrew) and I would only like to add an -> explanation why I have not split this change further. Certainly it is -> functionally consistent. Then adding i2c-swarm.c only breaks things as -> the onchip buses suddenly get the numbers 2 and 3. On the other hand, if -> adding the i2c-sibyte.c change only, it will take a while until it -> propagates back to the MIPS tree and without that as it is there is no -> single way to use the whole set of changes as the clock device will not be -> seen. -> -> If you are scared off by the MIPS-specific Makefile (lib vs obj) changes, -> then I think they should be reasonably easy to sort out separately in a -> couple of days as functionally not changing anything. The only other file -> in the affected subdirectory that depends on a config option uses -> CONFIG_KGDB which does not seem to rely on being pulled implicitly by the -> linker. But such a mechanical change by itself would make little sense -> (don't fix what isn't broken), so I have not pushed it without a -> reasonable justification. -> -> Ralf -- what do you think about the Makefile changes? I can send you a -> separate patch which will reduce the span of this one. - -That's not a matter of being scared, and I was also _not_ asking you to -split the patch. That's a matter of synchronizing merges between me and -the architecture maintainer. If I take a patch in my i2c tree which -touches architecture-specific files, and I only push it to Linus in 2 -months, then chances are that the architecture-specific files in -question will change several times meanwhile, resulting in conflicts in --next and -mm. I am only trying to prevent this from happening. I -simply think that it is easier to synchronize patches if all -architecture-specific patches go through the relevant architecture tree. - -BTW, SWARM seems to be only one of the 4 SiByte platforms we support. -What about the other ones? Your changes to the i2c-sibyte driver could -cause the i2c bus registration to fail, as the other platforms do not -declare I2C devices, the bus numbers 0 and 1 won't be reserved by -i2c-core. Care to comment on this? - -Thanks, --- -Jean Delvare diff --git a/a/content_digest b/N1/content_digest index efbfed5..fe39ed1 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -51,82 +51,6 @@ "> \n" "> This is mostly habitual -- this is what the GNU Coding Standard specifies\n" "> for comments and which is enforced for GNU software which I have dealt a\n" - "> lot with.\n" - "\n" - "From Documentation/CodingStyle:\n" - "\n" - "\"First off, I'd suggest printing out a copy of the GNU coding standards,\n" - "and NOT read it. Burn them, it's a great symbolic gesture.\"\n" - "\n" - "I'm not going to tell how bad I think the GNU coding standards are, the\n" - "point here is that we don't follow them at all, so whatever they say is\n" - "totally irrelevant. Read Documentation/CodingStyle, it describes what\n" - "we do. Also make sure that you run your patches through\n" - "scripts/checkpatch.pl. The rest is up to you, but in general, when\n" - "modifying existing code, you want to stick to what the surrounding code\n" - "looks like.\n" - "\n" - "> I think the idea is it improves readability and I tend to\n" - "> agree. The same goes for using a capital at the beginning and a full stop\n" - "> at the end of sentences in comments -- it improves readability and\n" - "> (together with a good style of code itself) makes the result look more\n" - "> professional. Certainly well-formatted code is easier to comprehend for \n" - "> someone looking at it for the first time.\n" - "> \n" - "> I do not insist on the extraneous space if you have a strong opinion \n" - "> against though.\n" - "\n" - "I do insist ;) Admittedly, double spaces at end of comments are used in\n" - "some places in the kernel tree (I had never seen that before), but they\n" - "are still outnumbered by single-space ending comments, 50 to 1. Do\n" - "what you want in the drivers your create or maintain, but please don't\n" - "change existing comments, especially not in the middle of functional\n" - "changes.\n" - "\n" - "> > I'm not sure how you intend to push these changes upstream. I would\n" - "> > take a patch only touching drivers/i2c/busses/i2c-sibyte.c in my i2c\n" - "> > tree, however a patch also touching arch code, must be handled be the\n" - "> > maintainer for that architecture or platform.\n" - "> \n" - "> Andrew has spoken (thank you, Andrew) and I would only like to add an\n" - "> explanation why I have not split this change further. Certainly it is\n" - "> functionally consistent. Then adding i2c-swarm.c only breaks things as\n" - "> the onchip buses suddenly get the numbers 2 and 3. On the other hand, if\n" - "> adding the i2c-sibyte.c change only, it will take a while until it\n" - "> propagates back to the MIPS tree and without that as it is there is no\n" - "> single way to use the whole set of changes as the clock device will not be\n" - "> seen.\n" - "> \n" - "> If you are scared off by the MIPS-specific Makefile (lib vs obj) changes,\n" - "> then I think they should be reasonably easy to sort out separately in a\n" - "> couple of days as functionally not changing anything. The only other file\n" - "> in the affected subdirectory that depends on a config option uses\n" - "> CONFIG_KGDB which does not seem to rely on being pulled implicitly by the\n" - "> linker. But such a mechanical change by itself would make little sense \n" - "> (don't fix what isn't broken), so I have not pushed it without a \n" - "> reasonable justification.\n" - "> \n" - "> Ralf -- what do you think about the Makefile changes? I can send you a \n" - "> separate patch which will reduce the span of this one.\n" - "\n" - "That's not a matter of being scared, and I was also _not_ asking you to\n" - "split the patch. That's a matter of synchronizing merges between me and\n" - "the architecture maintainer. If I take a patch in my i2c tree which\n" - "touches architecture-specific files, and I only push it to Linus in 2\n" - "months, then chances are that the architecture-specific files in\n" - "question will change several times meanwhile, resulting in conflicts in\n" - "-next and -mm. I am only trying to prevent this from happening. I\n" - "simply think that it is easier to synchronize patches if all\n" - "architecture-specific patches go through the relevant architecture tree.\n" - "\n" - "BTW, SWARM seems to be only one of the 4 SiByte platforms we support.\n" - "What about the other ones? Your changes to the i2c-sibyte driver could\n" - "cause the i2c bus registration to fail, as the other platforms do not\n" - "declare I2C devices, the bus numbers 0 and 1 won't be reserved by\n" - "i2c-core. Care to comment on this?\n" - "\n" - "Thanks,\n" - "-- \n" - Jean Delvare + > lot with. -9f2dce990d32599ac6b3988d21a49dee66e0db95bb11c7b8733a38220f3f90f6 +1a92b89856ee4ebb28bd4e3157c46333da6bb6574deabc027e38a375285c9a17
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox