On Sun, Mar 14, 2021 at 01:06:51AM +0200, Vladimir Oltean wrote:
On Sat, Mar 13, 2021 at 02:20:15PM -0500, Sasha Levin wrote:
On Sat, Mar 13, 2021 at 08:51:31PM +0200, Vladimir Oltean wrote:
> On Sat, Mar 13, 2021 at 11:10:57AM -0500, Sasha Levin wrote:
> But the question surprises me. I thought the M.O. is that somebody
> should explain _why_ a commit should go to a stable tree, not why it
> shouldn't. I notice now that most, if not all, of that series ended up in
> linux-5.10.y, which I most definitely did not expect. It's not that it
> will do any harm there, but more like I feel that we as maintainers
> don't have any sort of control over what a stable kernel becomes over
> time; we think we left it in a certain state and we see it change unexpectedly.
> The thought process when sending a patch to David Miller's "net" tree vs
> "net-next" is different - you know that what you send to "net-next" only
> needs to work on the current tree, whereas for "net" you want to be as
> compatible as possible with code that existed in past releases. The fact
> that you need to watch your back for stuff sent to net-next is unpleasant.
> Now I'll have to go give linux-5.10.y a run and see if everything is ok
> there.
But in the end commits end up in the same spot in Linus's tree, so we
don't have a way to tell which tree they went through.
Exactly my point, if I send a patch during the development cycle for
5.11 and it ends up, unknowingly to me, in 5.10, there's a problem.
Are you sitting on fixes until -rc1? You shouldn't be doing that, fixes
go out during the merge window as well.
Sadly, though, most of Greg's mails regarding failed patches end up
being ignored so it falls back on us to try and do the backport. (note
I'm not saying that *you're* ignoring them, just in general that we've
had a low response rate to these so we end up doing backports
ourselved).
So let's recap the involved parties:
- Qingfang is the author of the patch which failed to be backported.
He wants his OpenWRT on the Mediatek Ethernet switch to work, has a
bunch of still-downstream patches, his strategy is that of eventual
consistency with mainline Linux, doesn't really care what's in
linux-5.10.y. He ignores your backport failure notification.
- You are a linux-stable maintainer. You have some upfront commitments
with vendors who care about linux-5.10.y being up to date with respect
What commitments? what vendors? what are you talking about?
No, no one is paying me to have 5.10 be up to date with anything.
to bugfixes, and a ton more vendors who aren't upfront about it.
Either way, you care about what goes into linux-5.10.y, so you make a
judgement call to be proactive about it and backport 13 unnecessary
patches in order for that one, which Qingfang didn't care enough
about, to apply.
Right, this is our standard workflow. Nothing special was done for this
bugfix, we would always take dependencies over a backported single
patch.
- I am a DSA maintainer, I care about what goes into linux-5.10.y too.
Not only does my company use it, but netdev@xxxxxxxxxxxxxxx also gets
the odd support question from time to time, where sometimes I can give
a helping hand too. A lot of people use LTS kernels, and you decide
you should change the API between the DSA framework and the transmit
procedure of the drivers, which impacts what the users get to work
What users? this is all in-kernel, right? we never touch userspace ABI.
with, however I am not even notified of changes to the code I should
offer support for? Mind you, I only became aware to the mass
backporting of 13 patches because my name was on one of them, not
because I maintain that area. For example, right now, Andrew Lunn or
Vivien Didelot probably still have no idea of what's going on.
And somehow we optimize for Qingfang?
We optimize for getting correct fixes in stable trees.
Come on, we've given up our souls to ./scripts/get_maintainer.pl for
a reason, we're ready to take the spam, don't be shy. I could have at
least been given a chance to say 'don't bulk-backport 13 patches, I
haven't thought of all the consequences of doing that, nor have I
tested them there'.
So we're actually discussing this very early: the -rc that will have
these patches didn't even go out yet. This entire discussion is based
around our internal addition of patches to the queue, which in general
doesn't mean anything (we usually do that to trigger a bunch of
automated testing).
If the -rc mail that Greg will send out doesn't actually get to
maintainers, it's worth dragging him in this discussion to understand
why not.
--
Thanks,
Sasha
