* [GIT PULL] clockevents/clocksource: 3.12 fixes
@ 2013-11-12 22:57 ` Thomas Gleixner
0 siblings, 0 replies; 14+ messages in thread
From: Thomas Gleixner @ 2013-11-12 22:57 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, 12 Nov 2013, Uwe Kleine-K?nig wrote:
> On Tue, Nov 12, 2013 at 03:01:29PM +0100, Daniel Lezcano wrote:
> >
> > Hi Ingo and Thomas,
> >
> > this pull request has the following contain:
> >
> > * Laurent Pinchard fixed a missing a clk_put in case the
> > registering of the sh_mtu[2] drivers fails.
> >
> > * Uwe Kleine-K?nig reuse clockevents_config_and_register for the
> > at91rm9200_time timer as it was depending on the patch (commit
> > a4578ea (clockevents: Sanitize ticks to nsec conversion).
> >
> > I don't know why Thomas's patch "clockevents: Sanitize ticks to nsec
> > conversion" appears in the request log because it is not part of the
> > patches interval I specified for git request pull. The diffstat does
> > not show the files which should have been changed by the patch. In
> > any case I kept the changelog untouched since it is what gives me
> > git and maybe someone can tell me why it appears.
> Look at:
>
> git log --oneline --graph --boundary 97b9410..42ab380
>
> Then you see that there is Thomas' patch twice. Once the version he
> committed and sent to Linus (97b9410) and once the version that you get
> as part of my pull request (a4578ea). To fix this (assuming you don't
> care much about a stable tree), simply do:
>
> git rebase 97b9410 42ab380
>
> and let the result pull.
The whole misery starts that you decided to play maintainer and grab
some patches from the mailinglist and then offering them via a pull
request to me and others. Finally you tricked Daniel to take them,
which is a different issue.
There is a reason why I ignored that pull request:
I generally do not pull git trees from people who I'm not
trusting. And I have good reasons not to trust you at all.
Aside of that, I decided to give you a chance and actually pulled
your tree into a temporary branch and found out that it's missing a
stable annotation. Which made the whole exercise go into /dev/null
Now Linus pulled my version way before Daniel pulled your tree into
his. And you even commented on my commit that I forgot to add a
tested-by tag. Yes, I missed that in favour of the stable annotation.
But instead of rebasing your tree or even just withdrawing it and
resending the at91 patch, you let Daniel pull your thing.
Of course Daniel failed to detect the pointless commit in your pull
request at the point of merging it and then he starts asking questions
when he sends the pull request for his aggregated stuff ....
There is a good reason why most maintainers have a strict policy from
whom they are pulling from and from whom they are just accepting
patches by mail.
Daniel, please provide me a rebased version, but be more careful
versus integration of random pull requests next time.
Thanks,
tglx
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [GIT PULL] clockevents/clocksource: 3.12 fixes
2013-11-12 22:57 ` Thomas Gleixner
@ 2013-11-13 10:18 ` Daniel Lezcano
-1 siblings, 0 replies; 14+ messages in thread
From: Daniel Lezcano @ 2013-11-13 10:18 UTC (permalink / raw)
To: Thomas Gleixner, Uwe Kleine-König
Cc: Ingo Molnar, John Stultz, Laurent Pinchart,
Linux Kernel Mailing List, linux-arm-kernel
On 11/12/2013 11:57 PM, Thomas Gleixner wrote:
> On Tue, 12 Nov 2013, Uwe Kleine-König wrote:
>> On Tue, Nov 12, 2013 at 03:01:29PM +0100, Daniel Lezcano wrote:
>>>
>>> Hi Ingo and Thomas,
>>>
>>> this pull request has the following contain:
>>>
>>> * Laurent Pinchard fixed a missing a clk_put in case the
>>> registering of the sh_mtu[2] drivers fails.
>>>
>>> * Uwe Kleine-König reuse clockevents_config_and_register for the
>>> at91rm9200_time timer as it was depending on the patch (commit
>>> a4578ea (clockevents: Sanitize ticks to nsec conversion).
>>>
>>> I don't know why Thomas's patch "clockevents: Sanitize ticks to nsec
>>> conversion" appears in the request log because it is not part of the
>>> patches interval I specified for git request pull. The diffstat does
>>> not show the files which should have been changed by the patch. In
>>> any case I kept the changelog untouched since it is what gives me
>>> git and maybe someone can tell me why it appears.
>> Look at:
>>
>> git log --oneline --graph --boundary 97b9410..42ab380
>>
>> Then you see that there is Thomas' patch twice. Once the version he
>> committed and sent to Linus (97b9410) and once the version that you get
>> as part of my pull request (a4578ea). To fix this (assuming you don't
>> care much about a stable tree), simply do:
>>
>> git rebase 97b9410 42ab380
>>
>> and let the result pull.
>
> The whole misery starts that you decided to play maintainer and grab
> some patches from the mailinglist and then offering them via a pull
> request to me and others. Finally you tricked Daniel to take them,
> which is a different issue.
>
> There is a reason why I ignored that pull request:
>
> I generally do not pull git trees from people who I'm not
> trusting. And I have good reasons not to trust you at all.
>
> Aside of that, I decided to give you a chance and actually pulled
> your tree into a temporary branch and found out that it's missing a
> stable annotation. Which made the whole exercise go into /dev/null
>
> Now Linus pulled my version way before Daniel pulled your tree into
> his. And you even commented on my commit that I forgot to add a
> tested-by tag. Yes, I missed that in favour of the stable annotation.
>
> But instead of rebasing your tree or even just withdrawing it and
> resending the at91 patch, you let Daniel pull your thing.
>
> Of course Daniel failed to detect the pointless commit in your pull
> request at the point of merging it and then he starts asking questions
> when he sends the pull request for his aggregated stuff ....
>
> There is a good reason why most maintainers have a strict policy from
> whom they are pulling from and from whom they are just accepting
> patches by mail.
>
> Daniel, please provide me a rebased version, but be more careful
> versus integration of random pull requests next time.
Yes I will. Thanks for catching this.
I overwrote my branch with a rebased version.
The following changes since commit 97b9410643475d6557d2517c2aff9fd2221141a9:
clockevents: Sanitize ticks to nsec conversion (2013-10-23 12:51:21
+0200)
are available in the git repository at:
git://git.linaro.org/people/dlezcano/linux.git clockevents/fixes
for you to fetch changes up to f578caebe38b87e7923cc03fb135d1e759912709:
clocksource: sh_tmu: Add clk_prepare/unprepare support (2013-11-13
11:06:50 +0100)
----------------------------------------------------------------
Laurent Pinchart (4):
clocksource: sh_mtu2: Release clock when sh_mtu2_register() fails
clocksource: sh_mtu2: Add clk_prepare/unprepare support
clocksource: sh_tmu: Release clock when sh_tmu_register() fails
clocksource: sh_tmu: Add clk_prepare/unprepare support
Uwe Kleine-König (1):
ARM: at91: rm9200: switch back to clockevents_config_and_register
arch/arm/mach-at91/at91rm9200_time.c | 7 ++-----
drivers/clocksource/sh_mtu2.c | 16 ++++++++++++++--
drivers/clocksource/sh_tmu.c | 20 +++++++++++++++++---
3 files changed, 33 insertions(+), 10 deletions(-)
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply [flat|nested] 14+ messages in thread* [GIT PULL] clockevents/clocksource: 3.12 fixes
@ 2013-11-13 10:18 ` Daniel Lezcano
0 siblings, 0 replies; 14+ messages in thread
From: Daniel Lezcano @ 2013-11-13 10:18 UTC (permalink / raw)
To: linux-arm-kernel
On 11/12/2013 11:57 PM, Thomas Gleixner wrote:
> On Tue, 12 Nov 2013, Uwe Kleine-K?nig wrote:
>> On Tue, Nov 12, 2013 at 03:01:29PM +0100, Daniel Lezcano wrote:
>>>
>>> Hi Ingo and Thomas,
>>>
>>> this pull request has the following contain:
>>>
>>> * Laurent Pinchard fixed a missing a clk_put in case the
>>> registering of the sh_mtu[2] drivers fails.
>>>
>>> * Uwe Kleine-K?nig reuse clockevents_config_and_register for the
>>> at91rm9200_time timer as it was depending on the patch (commit
>>> a4578ea (clockevents: Sanitize ticks to nsec conversion).
>>>
>>> I don't know why Thomas's patch "clockevents: Sanitize ticks to nsec
>>> conversion" appears in the request log because it is not part of the
>>> patches interval I specified for git request pull. The diffstat does
>>> not show the files which should have been changed by the patch. In
>>> any case I kept the changelog untouched since it is what gives me
>>> git and maybe someone can tell me why it appears.
>> Look at:
>>
>> git log --oneline --graph --boundary 97b9410..42ab380
>>
>> Then you see that there is Thomas' patch twice. Once the version he
>> committed and sent to Linus (97b9410) and once the version that you get
>> as part of my pull request (a4578ea). To fix this (assuming you don't
>> care much about a stable tree), simply do:
>>
>> git rebase 97b9410 42ab380
>>
>> and let the result pull.
>
> The whole misery starts that you decided to play maintainer and grab
> some patches from the mailinglist and then offering them via a pull
> request to me and others. Finally you tricked Daniel to take them,
> which is a different issue.
>
> There is a reason why I ignored that pull request:
>
> I generally do not pull git trees from people who I'm not
> trusting. And I have good reasons not to trust you at all.
>
> Aside of that, I decided to give you a chance and actually pulled
> your tree into a temporary branch and found out that it's missing a
> stable annotation. Which made the whole exercise go into /dev/null
>
> Now Linus pulled my version way before Daniel pulled your tree into
> his. And you even commented on my commit that I forgot to add a
> tested-by tag. Yes, I missed that in favour of the stable annotation.
>
> But instead of rebasing your tree or even just withdrawing it and
> resending the at91 patch, you let Daniel pull your thing.
>
> Of course Daniel failed to detect the pointless commit in your pull
> request at the point of merging it and then he starts asking questions
> when he sends the pull request for his aggregated stuff ....
>
> There is a good reason why most maintainers have a strict policy from
> whom they are pulling from and from whom they are just accepting
> patches by mail.
>
> Daniel, please provide me a rebased version, but be more careful
> versus integration of random pull requests next time.
Yes I will. Thanks for catching this.
I overwrote my branch with a rebased version.
The following changes since commit 97b9410643475d6557d2517c2aff9fd2221141a9:
clockevents: Sanitize ticks to nsec conversion (2013-10-23 12:51:21
+0200)
are available in the git repository at:
git://git.linaro.org/people/dlezcano/linux.git clockevents/fixes
for you to fetch changes up to f578caebe38b87e7923cc03fb135d1e759912709:
clocksource: sh_tmu: Add clk_prepare/unprepare support (2013-11-13
11:06:50 +0100)
----------------------------------------------------------------
Laurent Pinchart (4):
clocksource: sh_mtu2: Release clock when sh_mtu2_register() fails
clocksource: sh_mtu2: Add clk_prepare/unprepare support
clocksource: sh_tmu: Release clock when sh_tmu_register() fails
clocksource: sh_tmu: Add clk_prepare/unprepare support
Uwe Kleine-K?nig (1):
ARM: at91: rm9200: switch back to clockevents_config_and_register
arch/arm/mach-at91/at91rm9200_time.c | 7 ++-----
drivers/clocksource/sh_mtu2.c | 16 ++++++++++++++--
drivers/clocksource/sh_tmu.c | 20 +++++++++++++++++---
3 files changed, 33 insertions(+), 10 deletions(-)
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [GIT PULL] clockevents/clocksource: 3.12 fixes
2013-11-12 22:57 ` Thomas Gleixner
@ 2013-11-13 10:36 ` Uwe Kleine-König
-1 siblings, 0 replies; 14+ messages in thread
From: Uwe Kleine-König @ 2013-11-13 10:36 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Daniel Lezcano, Ingo Molnar, John Stultz, Laurent Pinchart,
Linux Kernel Mailing List, linux-arm-kernel
Hi Thomas,
On Tue, Nov 12, 2013 at 11:57:46PM +0100, Thomas Gleixner wrote:
> The whole misery starts that you decided to play maintainer and grab
> some patches from the mailinglist and then offering them via a pull
> request to me and others. Finally you tricked Daniel to take them,
>From my POV this isn't "playing maintainer". You stopped reacting on the
issue and I thought I make it easier for you (and others) to handle the
patches in case you didn't take because of being busy with other stuff.
> which is a different issue.
>
> There is a reason why I ignored that pull request:
>
> I generally do not pull git trees from people who I'm not
> trusting. And I have good reasons not to trust you at all.
>
> Aside of that, I decided to give you a chance and actually pulled
> your tree into a temporary branch and found out that it's missing a
> stable annotation. Which made the whole exercise go into /dev/null
I didn't add that stable annotation because I didn't want to add it
without you being ok with it. And actually it's easy to get a patch into
stable that isn't annotated. The other way round is harder.
> Now Linus pulled my version way before Daniel pulled your tree into
> his. And you even commented on my commit that I forgot to add a
> tested-by tag. Yes, I missed that in favour of the stable annotation.
>
> But instead of rebasing your tree or even just withdrawing it and
> resending the at91 patch, you let Daniel pull your thing.
To be fair Daniel said to take my pull request a few days before your
tip-bot told me that you finally took the patch. I could argue that it
was your turn to tell Daniel that you took a part of the patches that
were in my pull request. (But I don't as the situation it handled now
and even if not, the only bad thing that would have happend is that
another patch is duplicated in the history. shrug)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply [flat|nested] 14+ messages in thread
* [GIT PULL] clockevents/clocksource: 3.12 fixes
@ 2013-11-13 10:36 ` Uwe Kleine-König
0 siblings, 0 replies; 14+ messages in thread
From: Uwe Kleine-König @ 2013-11-13 10:36 UTC (permalink / raw)
To: linux-arm-kernel
Hi Thomas,
On Tue, Nov 12, 2013 at 11:57:46PM +0100, Thomas Gleixner wrote:
> The whole misery starts that you decided to play maintainer and grab
> some patches from the mailinglist and then offering them via a pull
> request to me and others. Finally you tricked Daniel to take them,
>From my POV this isn't "playing maintainer". You stopped reacting on the
issue and I thought I make it easier for you (and others) to handle the
patches in case you didn't take because of being busy with other stuff.
> which is a different issue.
>
> There is a reason why I ignored that pull request:
>
> I generally do not pull git trees from people who I'm not
> trusting. And I have good reasons not to trust you at all.
>
> Aside of that, I decided to give you a chance and actually pulled
> your tree into a temporary branch and found out that it's missing a
> stable annotation. Which made the whole exercise go into /dev/null
I didn't add that stable annotation because I didn't want to add it
without you being ok with it. And actually it's easy to get a patch into
stable that isn't annotated. The other way round is harder.
> Now Linus pulled my version way before Daniel pulled your tree into
> his. And you even commented on my commit that I forgot to add a
> tested-by tag. Yes, I missed that in favour of the stable annotation.
>
> But instead of rebasing your tree or even just withdrawing it and
> resending the at91 patch, you let Daniel pull your thing.
To be fair Daniel said to take my pull request a few days before your
tip-bot told me that you finally took the patch. I could argue that it
was your turn to tell Daniel that you took a part of the patches that
were in my pull request. (But I don't as the situation it handled now
and even if not, the only bad thing that would have happend is that
another patch is duplicated in the history. shrug)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [GIT PULL] clockevents/clocksource: 3.12 fixes
2013-11-13 10:36 ` Uwe Kleine-König
@ 2013-11-13 13:53 ` Thomas Gleixner
-1 siblings, 0 replies; 14+ messages in thread
From: Thomas Gleixner @ 2013-11-13 13:53 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Daniel Lezcano, Ingo Molnar, John Stultz, Laurent Pinchart,
Linux Kernel Mailing List, linux-arm-kernel
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1522 bytes --]
On Wed, 13 Nov 2013, Uwe Kleine-König wrote:
> On Tue, Nov 12, 2013 at 11:57:46PM +0100, Thomas Gleixner wrote:
> > The whole misery starts that you decided to play maintainer and grab
> > some patches from the mailinglist and then offering them via a pull
> > request to me and others. Finally you tricked Daniel to take them,
> >From my POV this isn't "playing maintainer". You stopped reacting on the
> issue and I thought I make it easier for you (and others) to handle the
> patches in case you didn't take because of being busy with other stuff.
Yes, I vanished for a few weeks because I was busy otherwise. Where is
the problem? The world was still turning and the fix was not a highly
critical issue.
And your "make it easier" thing is utter bullshit. It takes me less
time to apply a single patch from mail than pulling a tree and
verifying the commit.
Aside of that, core code goes always directly through me and not via
Daniel.
Dammit, there are established workflows and there is no reason, except
for a highly critical bug fix to circumvent them. And if such a
situation happens, then the correct thing is to resend the patch to
Andrew and Linus and explaining, why its critical and can't wait for
the lazy maintainer to reappear.
Me and others have observed your busybody behaviour often enough. It
does not really earn you trust and respect.
Just for the record: I'm not pulling anything from you and I'm not
going to pull a tree from my submaintainers which contains a merge
from you.
Thanks,
tglx
^ permalink raw reply [flat|nested] 14+ messages in thread
* [GIT PULL] clockevents/clocksource: 3.12 fixes
@ 2013-11-13 13:53 ` Thomas Gleixner
0 siblings, 0 replies; 14+ messages in thread
From: Thomas Gleixner @ 2013-11-13 13:53 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, 13 Nov 2013, Uwe Kleine-K?nig wrote:
> On Tue, Nov 12, 2013 at 11:57:46PM +0100, Thomas Gleixner wrote:
> > The whole misery starts that you decided to play maintainer and grab
> > some patches from the mailinglist and then offering them via a pull
> > request to me and others. Finally you tricked Daniel to take them,
> >From my POV this isn't "playing maintainer". You stopped reacting on the
> issue and I thought I make it easier for you (and others) to handle the
> patches in case you didn't take because of being busy with other stuff.
Yes, I vanished for a few weeks because I was busy otherwise. Where is
the problem? The world was still turning and the fix was not a highly
critical issue.
And your "make it easier" thing is utter bullshit. It takes me less
time to apply a single patch from mail than pulling a tree and
verifying the commit.
Aside of that, core code goes always directly through me and not via
Daniel.
Dammit, there are established workflows and there is no reason, except
for a highly critical bug fix to circumvent them. And if such a
situation happens, then the correct thing is to resend the patch to
Andrew and Linus and explaining, why its critical and can't wait for
the lazy maintainer to reappear.
Me and others have observed your busybody behaviour often enough. It
does not really earn you trust and respect.
Just for the record: I'm not pulling anything from you and I'm not
going to pull a tree from my submaintainers which contains a merge
from you.
Thanks,
tglx
^ permalink raw reply [flat|nested] 14+ messages in thread