On Tue, Jul 17, 2012 at 8:22 PM, Freddie Chopin <[email protected]> wrote: > W dniu 2012-07-17 16:14, Andreas Fritiofson pisze: >> Speak for yourself, I would certainly not consider avoiding giving >> negative review because of a rule like this. > > "Rule" is a wrong word here - I'm not a native speaker in English, so > maybe I have problems expressing what exactly I meant by this patch - > it's really just a "last resort" solution when the person who gave > negative review cannot be reached and does not re-review the updated > change. It should not be seen as a "hard rule" which gets executed with > sub-second precision after the timeout passed...
Well, I too meant rule in a looser sense. One you have the possibility to use. Or take another route. Or wait a bit longer. You wrote "may use" so I think it was clear. > The only thing MPSSE patch changed in rest of the code is use of > libusb-1.0 for stlink and jlink (probably) - not a big problem imho. And that is only if it's configured in with --enable-ftdi. >> Seeing that the community lacks the energy to review (architecturally >> and not style-wise) significant patches (and contributing in pre-patch >> discussions), I'm kind of put off by the work required. > > I don't care much about the style, as long as it's not a complete mess (; Style and details are important, but for the first version of a (large, non-trivial) change, a contributor wants feedback primarily on the big ideas of the change, not on details. Style can be easily adjusted whenever. A complete rewrite is not fun to have to make after several rounds of style-fixing work. > First of all I'm not a PC programmer. I also don't think it's the right > thing to do to change someones patches - in "major" things, "minor" > stuff would probably be OK (like order or patches, some typos, marking > parts of code as tested when they were marked as experimental, etc.). Well, I agree (both as reviewer and author) that it's a bit taboo to mess with other's patches. On the other hand patch sets in gerrit can be viewed as suggestions. Anyone can make a suggestion for a slightly different version of a patch. It's not necessarily the latest patch set that must to be the one that gets submitted. If everyone agrees on that view, it's easier to allow yourself to push an improved version of someone else's patch. There may also be legal issues involved, as it occurs to me now. Patches do not generally have to be licensed as GPL until they are merged with OpenOCD, thereby creating a derived work. So it's not safe to assume that anyone has a right to use patches in gerrit as they see fit. The author has pushed a work to gerrit for the purpose of merging it into OpenOCD, and has thereby implicitly licensed it for inclusion into mainline OpenOCD, where that derived work will be licensed as GPL. If the patch is not accepted, nothing says that it's legal to use the patch for anything else, including creating new versions (derived works) of the patch and merging that with OpenOCD, or using it in another project. Of course, IANAL and all that garbage. /Andreas ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
