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? -- Chris Ball <cjb@xxxxxxxxxx> <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
