On 2012.05.07 09:22, Ludovic Rousseau wrote: > Pete, to avoid any more problems in the future maybe you should > refrain from editing patches from others.
If you think there ever was a problem, then Peter successfully managed to make you believe that he had a say as to the content of the patch or the commit message, which he hasn't. The idea on the contrary, is that to avoid problems and be efficient with our time constraints, which is the one issue we need to address at all times, we should very much have the ability to edit patches as we see fit, especially as we're expected to constantly pick items from libusb and add ontop of them for libusbx usage. Let's consider this patch. If we were to do it the way you advocate, we'd have picked up Peter's commit, submitted it for review (with some possible small modifications for libusbx retrofit) while indicating that the thread ID addon would be handled in a subsequent patch. Ideally then, people would have first added this patch to their tree and tested (takes a little bit of time), possibly proposed a modification within the limited scope of the original patch (eg: output formatting), which people would (ideally) then have retested. OK, we're good, now we can integrate the patch. But wait, that's not all: now we want to add the thread ID, so here we go again reviewing a different patch, integrating it in one's own repo, testing it, commenting, potentially re-testing it, etc... Personally, I think it did make a lot of sense to address the review process with a single patch here, since not much was added and it very much pertains to the same feature, as it should save some time for everybody participating in the review process. And that's exactly what I aimed for. > I think it is better for code authorship attribution and project history. I think there's a threshold for which addons should be split into a separate commits, which is probably subjective to the person modifying the patch as well as the features being dealt with plus the time constraints, and which I didn't see being reached here. As to project history, I already indicated that there was hardly anything to be gained here, especially as we can hardly be expected to provide consistent referencing to libusb.git commits when we are likely to pick and integrate patches of interest submitted to the libusb-devel mailing list before they are integrated in libusb.git (which is one of the reasons we forked). Regards, /Pete ------------------------------------------------------------------------------ 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/ _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
