Re: [PATCH 16/60] Implement function to send md_reconnect_mdl_req

["Gustavo F. Padovan" <gustavo@padovan.org>]

Hi Santiago,

* Santiago Carot-Nemesio <scarot@libresoft.es> [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@gmail.com>
> >>>        
> >> 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