Hi, On Fri, Jul 23, 2010 at 12:58 PM, Johan Hedberg <johan.hedberg@xxxxxxxxx> wrote: > The SDP code in libbluetooth is probably the absolute worst place to > look for good examples. In this case the second variable in the function > is completely unnecessary. Just assign the malloc return directly to the > mcap_md_req pointer and get rid of the uint8_t* variable. > > Btw, I'd like to understand why we should use different acceptance > criteria for your patches compared to everything else that gets > submitted to BlueZ. The convention (which I'm sure you've noticed if you > follow the list) is that when issues are found in submitted patches the > submitter is requested to fix the issue in the patch and resubmit a new > version of the patch. You're essentially requesting for buggy patches to > be accepted as such and only fix the issues through new patches on top > of the buggy ones. I completely agree with this, one of the reason for this convention is that we don't want this changes split apart because they probably cannot be reverted individually. Another point is the history will be completely disorganized if we start to accept those fixes separately, it worth mention that this can eventually happen with patches already upstream, but then it is normally a regression fix and as such we normally mention the original commit which has caused it. I would understand if we were in the old days of cvs, but with git it is pretty simple to rearrange the changes, just use git rebase -i + git reset or whatever other form to get this fixed in place. -- Luiz Augusto von Dentz Computer Engineer -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
