On Wed, Jan 05, 2011 at 04:57:57PM +0000, Chris Ball wrote: > Wow, how hostile -- insult first, ask questions later? I do review and > merge MMC patches; all it takes is a ping to let me know that the tmio > maintainer is absent and that you'd like me to start picking these up. > I'd seen them being taken into other trees, and no-one's asked me about > merging any of them into the MMC tree before, so I didn't realize there > was a problem. We just need more communication. > 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. 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. 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. -- 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
