Mauro Carvalho Chehab wrote: > Steven Toth wrote: >>> That said, if getting even trivial changes like moving a few functions >>> around are going to be met with such resistance and come at an >>> enormous cost, it's *very* tempting to just host it locally and not >>> submit it upstream at all. >> Mauro, >> >> It makes no sense to have Kernel Labs work out of tree. Clearly in some >> cases this makes a lot of short term sense but rarely does this scale >> long term. I can speak to this from first hand experience. Generally it >> leads to bit-rot and unhappy developers, unhappy community and unhappy >> users. >> >> We are cleanup up the existing tree and fixing major oops prior to a >> massive amount of analog work. We've spent the time partitioning the >> code (like all of the other drivers) into sub-units -video.c, -dvb.c as >> this simplifies peer-to-peer remote development. It breeds commonality >> between drivers and eases long-term support for developers familiar with >> other drivers. >> >> The end goal is to show a clear and concise series of patches showing >> migration from the driver as-is to something much more stable and >> commercial grade. We can demonstrate a clean implementation and have >> near-zero development conflicts. I see no failure on our part. >> >> I see this as positive and pro-active peer-to-peer remote development >> practices. >> > > I agree with this concept. Breaking a big file into logically related > separate files makes sense. Yet, Devin's commented on irc that the code > on those files (ngene-av and ngene-eeprom) are from some hardware that you're > not working, nor have any plans to deal with them currently. So, the patches > would be just adding some dead code into some files that may never be > touched. That's why I said him that the better is to just drop it. The original > code is at -hg tree, and, people can use it any time it would be needed. > > I did something like that in December, when I've added ISDB-T support into > Siano driver: I got the history of siano include files, restored the ISDB-T > structures and wrote the code for the ISDB-T stats, based on it. > >> In fairness to you, I also understand your comments and they are also >> valid concerns. We are mindful of your authority and aware of your needs >> to keep the tree clean and optimal. On balance I think we both want the >> same end goal. Good code, clean patches, understandable small changes >> showing slow evolution. >> >> I hope you can see a way forward for the ngene tree that doesn't mean we >> are forced to house it away from linuxtv.org. This would be a great pity >> and against the spirit of community development. > > That's said, if I understood Devin wrong or if you now have plans to add some > real code at the new ngene-av and ngene-eeprom files, that's fine for me. > I'll happily accept a patch that moves that code to another file and enable > the code to read eeprom and to use the AV part, even if you do it on separate > patches, inside the same pull request. Hmm... this were badly written, partially due to a typo. So let me re-phrase it: If my understanding from Devin's chat were wrong and if you actually have plans to add some working code at the new ngene-av and ngene-eeprom files, that's fine for me. I'll happily accept a patch that moves that code to another file and enable the code to read eeprom and to use the AV part, even if you do it on separate patches, inside the same pull request. -- Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
