+Linus

Background:

Basically, Jason and myself developed an approach to fix a problem in
the RTC layer - https://marc.info/?t=150590661600002&r=1&w=3

John Stultz saw that discussion had ceased, and decided to merge the
cross-subsystem patch for 4.15.  Then, last week, Alexandre spots it
in mainline and decides he doesn't like it on fairly weak technical
grounds - see second message in:

https://marc.info/?t=150791745000009&r=1&w=3

I believe the grounds that Alexandre objects on are fairly weak as I
detailed in my replies to his objection.

What I can't fathom is why it would take someone two months to come
up with weak arguments against an approach, and then when I complain
about that and the prospect of it being reverted on those grounds,
the reaction is to revert it.

IMHO, maintainers have a duty to respond within a reasonable timescale,
and if patches get merged inspite of them, they need to consider
whether they're really doing a good job in the first place, and whether
they have *really good* reasons to object.

If maintainers are going to sit back, and let people work on problems,
and then have patches reverted only after they hit mainline, people are
just going to stop working on trying to solve problems - because no one
will know whether their approach is acceptable or whether they're merely
wasting their time.  That would be /very/ bad for Linux.

On Mon, Nov 27, 2017 at 06:53:52PM +0000, Russell King - ARM Linux wrote:

On Mon, Nov 27, 2017 at 07:44:11PM +0100, Alexandre Belloni wrote:

quoted

On 27/11/2017 at 17:52:54 +0000, Russell King - ARM Linux wrote:

quoted

I'm actually rather disappointed that Alexandre Belloni has only now
brought up his dis-satisfaction with the approach after all the effort
that Jason and myself have put in to it.  It's not like Alexandre was
not copied on the patches and discussion.

If Alexandre could not be bothered to bring up his concerns while the
discussion was on-going in September, and didn't bother raising them
in October, I'd say that Alexandre's opinion at this point doesn't
count for much - if it wasn't important to state at the time or for
a couple of months after, why does it become important to state after
the thing has been merged.

Maybe the idea here is basically to waste people's time letting them
develop a patch for an approach, and then object at the last minute
to that approach.  Hardly seems fair or even reasonable.

How unfair that is! Really, you are not in a position to make that kind
of comment because you are not even replying to patches in your own
subsystem. But maybe my time doesn't count as much as yours.

You are, yet again, wrong.

I am in a position to make the comment because it was me who identified
the problem, put in the hours to work on, develop and extensively test
Jason's patch.  So, it's partly my time that you seem to be wasting,
and that gives me every right to complain at this point.

You, on the other hand, were copied with every single email, and did
nothing to discuss the issue except for the "easy" bits when I posted
a relatively smaller patch - but you ignored the bigger issue.

Now that the patch was merged, you throw your toys out of the pram and
start blaming everyone else for "silently" merging the patch and how it
wasn't sent to the right email addresses.

And now that someone dare criticise your abilities, you decide to revert
the change and restore Linux back to a crippled state.

Honestly, I don't _care_ if you revert it and if you want to cripple
the kernel as a result in regards to this issue, I can carry the patch
ad infinitum, no skin off my back.  You're only going to be hurting
yourself and other people through your spite by doing that revert.

I suggest you take a good long hard look at what you're about to do and
ask whether you are being reasonable, given that it's taken you over
two months whole months to raise any _technical_ issues with the approach
that Jason and myself came up with.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up