On Fri, 15 May 2009, Øyvind Harboe wrote: > > Attachments are annoying, but they avoid lots of odd issues that crop up > > when email clients get too eager to help. Things like trailing spaces and > > tab to space conversion tends to happen. Attachments are preserved much > > better in general. > > If things are leaning towards a bug tracking system, we could keep > patches in that system....
Personally, I consider bug tracking system even worse. Not that I contributed much to OpenOCD patch review (if at all) so far, but my time is just too limited for me to bother commenting on a patch that I have to save to a file then import back into my mailer in order to put my comments along side the parts of the patch I wish to comment on. Having to deal with a bug tracking system for commenting/reviewing patches constitute even more steps and is simply a turn-off for me. I'm deeply involved in a narrow part of the Linux kernel development, and in that world anything else but plain patches in the email body simply don't scale due to the manipulation overhead mentioned above. I do receive many many patches in my inbox every day. If I have the choice, I'll review patches for which I simply have to hit the reply button in my mailer and start inserting my comments inline right away over those that require any additional manipulations. With regard to mailers messing up tab and spaces... well, all I can say is that thousands of Linux developers do use mailers that can be made to preserve email body content, either by default or with some config settings since this is what the established patch review process requires. Many of those email clients are available on Windows and/or MAC too. And saving the email body to a file is usually just as easy as saving an attachment. Git even has a tool to pick up an email folder where you might have saved a bunch of patch-containing emails and apply them all. Note that I'm not asking for any particular requirements here. Simply stating how my review contribution is likely to be influenced by the patch channel. Nicolas
_______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
