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

Reply via email to