Conversation

@shironeko What about shrinking this to a minimally possible fix?

1
0
0
@oleksandr that would be great for the first 12 patches, the other 900 would be merge conflict hell.
1
0
0

@shironeko One doesn't have to merge 900 patches in one go in the first place.

1
0
0

@shironeko Thousands of backports going into one release.

1
0
0
@oleksandr I see yeah that's not really what I meant. I mean like as stable drifts away from the mainline the fixes gets harder and harder to apply.
1
0
0

@shironeko Just lets not apply what's not important ¯\_(ツ)_/¯.

1
0
0
@oleksandr is that what people want though? As far as I know the people that consume stable trees are people that run arch/fedora/tumbleweed/gentoo etc and the inclusion policy of stable trees matches that profile pretty well.
1
0
0

@shironeko Except regressions from excessive backporting, and that has to be patched by distro maintainers additionally.

1
0
0
@oleksandr that's exactly the tradeoff these bleeding edge distros make right? they are for people that trade some regression rate for latest features and improvements, and I would say that new chip enablement is exactly the sort of thing they would want to get.
1
0
0

@shironeko Bleeding edge? Probably. But they are using a "stable" kernel that literally declares itself as such, which is a discrepancy between the name and what it actually is.

1
0
1
@ljs @oleksandr I'm not the one cleaning things up all the time
1
0
1
@vbabka @oleksandr true, there is only one true cleanup king...

Elfring!
1
0
2

@ljs @vbabka @oleksandr 🔮will this cleanup further improve the software development process? 💭

0
0
2
@oleksandr it's stable with respect to latest (torvalds/linux), and it's what distros (and by extension their user) that consume the stable tree is looking for.
1
0
0