On 17 December 2012 16:46, Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> wrote: > On Mon, Dec 17, 2012 at 04:29:51PM +0100, Ulf Hansson wrote: >> Hi Russell and Chris, >> >> I would like to propose a change of how we handle mmci patches to be >> merged. Instead of going through Russell's arm tree, I would like >> Chris to handle the merge through his mmc tree. >> >> The reason is simply that patches can have dependencies to the >> protocol layer and in seems a bit unnecessary to wait for another >> merge window to occur to handle these patches. > > You're going to have to wait another merge window _anyway_ because no > kernel developer should be stuffing their tree full of patches during > any merge window that have not already been in linux-next well _before_ > the merge window. > I think you misunderstood me here. If I add a patch on the protocol layer, that will provide a new option for a host driver to support, I can not in same patchset send the mmci patch. I will have to put the mmci patch on hold for the next merge window to be completed and take through your tree instead. Thus I can not provide a "proof of concept" patch for mmci driver. That is really bad I think. > So like it or not, this merge window already closed to new submissions > maybe two weeks ago. Not talking about _a_ specific merge window. Just how we could go forward with a more simpler setup of merging patches. > >> Moreover, if most of the mmci patches goes through Chris mmc tree, I >> believe we would minimize the number of possible conflicts. Russell >> will then only need to NACK patches to prevent them from being merged. >> >> Do you think this could be and acceptable setup for both of you? > > The reason that you want to do this is because you're realising that it's > taking a long time for you to get your patches into mainline. The reason > that I'm being slow with your patches is that you haven't built up the > trust on my side that I can simply say "yes that's fine, I trust your > patches." You will only have to NACK patches to prevent them from going in. So there is no difference here from what we have today. I realize that trust is important, I am working on it. :-) > > That alone is good enough reason for me to say no way to this. Kind regards Ulf Hansson -- 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
