Hi Santiago, * Santiago Carot-Nemesio <scarot@xxxxxxxxxxxx> [2010-07-23 19:17:41 +0200]: > Hi, > On 07/23/10 13:30, Elvis Pfützenreuter wrote: > > On 23/07/2010, at 07:44, José Antonio Santos Cadenas wrote: > > > > > >> Hi, > >> > >> El Friday 23 July 2010 12:31:03 Luiz Augusto von Dentz escribió: > >> > >>> 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. > >>> > >> We agree with you two. This is the complete development history that we have > >> now. We sent it like this because we understood that keeping the history will > >> be better. We don't care sending a different history with all the bug > >> corrections amended. > >> > >> About the use of git rebase, it is not the first time that we do this and > >> because of this we know that rebase some commits will make some of the > >> following commits not compile. It will be a long and hard work to fix this, so > >> it will be better and easier to create a new "virtual" history that splits the > >> whole implementation in smaller patches. > >> > > In this line, it is better to put MCAP files inside health/ as Marcel asked. > Don't worry. I will set MCAP into health directory. I don't try to > explain anymore that MCAP is not only a health focused specification. It > is like I want to make program that only requires TCP to work and you > are forcing to me to import HTTP libraries, change HTTP by HDP and TCP > by MCAP and you will get the analogy. > I just hope that nobody get surprised if in the coming years are new > non-health related profiles that require use MCAP and you need import > Health to implement it. If that happens we can move to new 'mcap' directory. For now only HDP uses it, so makes sense keep iut inside health/ -- Gustavo F. Padovan http://padovan.org -- 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
