On 2012.07.03 08:33, Hans de Goede wrote: > Next time please send patches inline, that makes replying to them for a > review a lot easier.
This is getting old. The thing is, Segher complained once, so I went inline, then Xiaofan complained about the extra '>' character, so I reverted back to non inline. Note that I also recently had to reinstall Thunderbird (along with Windows...), so it's possible some of the defaults for patch attachments have been reset. Were you OK with the patches I sent a week ago and earlier? Also, since we're talking about attachments and inline, I find that the git e-mail patch format, which is what you sent your RFC patches into, makes it harder to identify patches as far as I'm concerned. I would very much prefer patches to be sent as actual attachments (preferably attached-inline, if that's what people prefer) as it makes it a lot easier, as a maintainer, to try to make sure one of them isn't falling through. For now I guess I'll revert back to attached inline, even though this'll probably inconvenience Xiaofan again... > Please also rename the enum type name, usbi indicates it is a libusb > internal thing, > I suggest using libusb_log_level instead. Good point, will do just that. Also, I just noticed that libusb-compat uses a log level ordering that is the reverse of libusb/libusbx (their _DEBUG is 0, libusb(x)'s is 4) which kind of vindicates the idea that you really want your log levels as enums/defines in the public API: even the same project can't manage consistency there. Now, unless libusb-compat uses naked log level numbers, which as far as I can see it does not, this shouldn't be a problem. 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