| Message ID | 528234B9.7080402@linaro.org |
|---|---|
| State | New |
| Headers | show |
Hello, 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. Best regards Uwe
On 11/12/2013 07:35 PM, Uwe Kleine-König wrote: > Hello, > > 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. Ah, yeah, I was suspecting something like that. Thanks a lot for the clarification. -- Daniel
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
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
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
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. Thanks -- Daniel 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 42ab3801115c2e2ae3d0467ecef943913bba8a2f: clocksource: sh_tmu: Add clk_prepare/unprepare support (2013-11-08 11:08:00 +0100) ---------------------------------------------------------------- Daniel Lezcano (1): Merge tag 'timer-for-tip' of git://git.pengutronix.de/git/ukl/linux into clockevents/fixes 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 Thomas Gleixner (1): clockevents: Sanitize ticks to nsec conversion 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(-)