[QUESTION] mmc: mmci: Howto merge patches

[QUESTION] mmc: mmci: Howto merge patches

[Ulf Hansson]

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.
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?

Kind regards
Ulf Hansson

[QUESTION] mmc: mmci: Howto merge patches

[Russell King - ARM Linux]

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.

So like it or not, this merge window already closed to new submissions
maybe two weeks ago.

> 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."

That alone is good enough reason for me to say no way to this.

[QUESTION] mmc: mmci: Howto merge patches

[Ulf Hansson]

On 17 December 2012 16:46, Russell King - ARM Linux
<linux@arm.linux.org.uk> 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