On Wed, 05.08.09 19:53, Lennart Poettering (lennart at poettering.net) wrote: > On Thu, 16.07.09 10:49, Zheng, Huan (huan.zheng at intel.com) wrote: > > > Previous mail is blocked due to large size, I separate the patch > > into 3, this is the second one. > > OK, this looks pretty good too. Not much to complain. Except maybe > that I don't like if you abbreviate volumes as "v" and mute statuses > as "m" in structs. It's fine to abbreviate in local variables. But > public fields, not so much. But this is just nitpicking from my side. > > Hmm, so your three patches look pretty good. Of course, multichannel > support would be good to have. But I think this looks good enough to > be merged, and multichannel support we still can add later on. > > I will now create a new git branch "merge-queue" and commit your patch > there. I think it is a bit too invasive to sneak this into 0.9.16 at > this point in time. After that release is out of the door I'll merge > the merge-queue into master, so that we'll have this fr 0.9.17. > > Thanks for your work! A few more notes: please make sure to include explanations in the patches themselves the next time, so that we have them in the git history. The whole point of allowing commit messages in the form of RFC822 messages is that we can have the original mails in them! Also, please watch whitespace issues more closely. Kernel folks tend to refuse patches with broken whitespace (i.e. trailing whitespace, trailing newline) outright. I don't but that doesn't mean patches must be full of them. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4
