Re: outstanding TMIO MMC patches

[Arnd Hannemann <arnd@arndnet.de>]

Hi Chris,

Am 05.01.2011 19:57, schrieb Chris Ball:
> On Thu, Jan 06, 2011 at 02:30:30AM +0900, Paul Mundt wrote:
>> Again, this isn't the first time this has happened. Any perceived
>> hostility in this matter is not directed at you directly since you did
>> come in to things rather late and were possibly unaware of the situation.
>> It's more absentee maintainers I have a problem with. In any event, you
>> were Cc'ed on mails that pointed out the problem (at least in summary),
>> you've presumably seen the mails with the patches that went by with pings
>> by people looking for answers, and it still took a strongly worded email
>> to elicit any sort of response. Make of that what you will.
> 
> A politely-worded email would have achieved just as good a response as the
> insultingly-worded one.  You should reach for politeness first when dealing
> with someone who might simply be misunderstanding your expectations of them.
> 
> Since I came in late, I've been reluctant to overrule driver maintainers
> without someone asking me to do so explicitly (I'm happy to do it when
> asked to).  I do sympathize with the frustration, though; let's move on.
> 
>> In any event, we seem to have shaken out the beginnings of a way forward
>> now, so this is progress!
>>
>>> So, let's come up with a workflow.  With Ian absent, it would be good to
>>> have someone with TMIO hardware (I don't have any) who's willing to help
>>> test and review/ACK patches.  I don't generally like to take arch code
>>> in through the MMC tree, so it would also be good to break up some of
>>> the patchsets into MMC-only if possible.
>>>
>> This is basically where the problem lies. Ian has some version of the
>> hardware that we don't, and he likewise doesn't have access to the
>> version that we do (of course there would be no problem in making the
>> hardware available to whoever decides to step up and look after TMIO in a
>> more constructive fashion, though). There are likewise issues with
>> regards to who has access to what specifications, and there are cases
>> where neither Ian nor any of the people from our side have any specs at
>> all. With this sort of a scenario it can be quite difficult to avoid
>> stepping on other peoples toes and making sure that things aren't being
>> inadvertently broken, and this is something I don't see any specific
>> resolution to, other than if you're not around to test and object in a
>> timely fashion, you lose. I don't know if other MMC drivers have the same
>> problem or not, but I can't imagine that this situation is terribly
>> unique when you have both corporations and hobbyists working on the same
>> driver from vastly different angles.
> 
> I see.  So, if most patches are coming from your side, it seems that the
> largest problem for the moment is that no-one except Ian can test your
> patches against his hardware.  Do we think there's any chance of someone
> (I guess ideally you but possibly me) getting hold of hardware with Ian's
> MMC block in, for at least occasional testing before releases?
> 
> If not, is there any kind of split in the driver that we could use to try
> to isolate changes more?
> 
> If not, I guess I agree that we just have to try and be clear about what
> we're merging and the chance that we're breaking something in the process.
> 
>> For the moment Guennadi and Arnd have been doing the work, with the
>> occasional patch from Magnus and others. All of this work however is done
>> on the same set of hardware and roughly by the same set of people with an
>> identical set of interests working for the same company, which makes
>> objective code review a bit problematic. Ian has provided useful feedback
>> in the past, which is why I've generally given him the benefit of the
>> doubt and let patches sit around for a month or two before pushing on
>> people. I note that the driver is 'maintained' for example instead of
>> 'supported', so it's understandable that people do somethings get pulled
>> away by other things from time to time. If one persistently can't even do
>> the bare minimum however, then it should simply be orphaned.
>>
>> As it is now however we are quickly building up an unwieldly patch stack
>> with more future work to be done, and I'm hesitant to have anyone begin
>> any future work when the existing dependencies are wildly out of sync
>> with upstream already. If we can get some sort of process in place that
>> makes this less of a problem, then of course I'm pretty open to anything.
>> The main thing I want to avoid is a feedback loop where things go in to
>> -mm purgatory, get bounced off of Ian once a month or so, and then the
>> process repeats itself.
> 
> Yes, I expect we can start by merging many of the outstanding patches.
> It looks like all except Arnd's six-part series can be merged via the
> MMC tree, since the MFD changes have an ACK from Samuel already. 
> I'll do that today.
> 
> Arnd, can I take just patches 1/2 from your six-part series, and have
> you send the rest through the arch/ maintainers later?

Sure, should be no problem.
Ah, just saw that you already pushed those two, thanks.

@Paul: 
Maybe it would be best that you ACK those arch patches (if you think
they are ok) and that they also go in via the mmc-next tree?
Otherwise we would need to wait until mmc-next for .38 is merged in your trees,
right?

Thanks,
Arnd