On Mon, Aug 12, 2019 at 03:22:26PM +0200, Michal Hocko wrote:
On Mon 12-08-19 15:14:12, Vlastimil Babka wrote:
On 8/12/19 10:45 AM, Michal Hocko wrote:
> On Sun 11-08-19 19:46:14, Sasha Levin wrote:
>> On Fri, Aug 09, 2019 at 03:17:18PM -0700, Andrew Morton wrote:
>>> On Fri, 9 Aug 2019 08:46:33 +0200 Michal Hocko <mhocko@xxxxxxxxxx> wrote:
>>>
>>> It should work if we ask stable trees maintainers not to backport
>>> such patches.
>>>
>>> Sasha, please don't backport patches which are marked Fixes-no-stable:
>>> and which lack a cc:stable tag.
>>
>> I'll add it to my filter, thank you!
>
> I would really prefer to stick with Fixes: tag and stable only picking
> up cc: stable patches. I really hate to see workarounds for sensible
> workflows (marking the Fixes) just because we are trying to hide
> something from stable maintainers. Seriously, if stable maintainers have
> a different idea about what should be backported, it is their call. They
> are the ones to deal with regressions and the backporting effort in
> those cases of disagreement.
+1 on not replacing Fixes: tag with some other name, as there might be
automation (not just at SUSE) relying on it.
As a compromise, we can use something else to convey the "maintainers
really don't recommend a stable backport", that Sasha can add to his filter.
Perhaps counter-intuitively, but it could even look like this:
Cc: stable@xxxxxxxxxxxxxxx # not recommended at all by maintainer
I thought that absence of the Cc is the indication :P. Anyway, I really
do not understand why should we bother, really. I have tried to explain
that stable maintainers should follow Cc: stable because we bother to
consider that part and we are quite good at not forgetting (Thanks
Andrew for persistence). Sasha has told me that MM will be blacklisted
from automagic selection procedure.
I'll add mm/ to the ignore list for AUTOSEL patches.
I really do not know much more we can do and I really have strong doubts
we should care at all. What is the worst that can happen? A potentially
dangerous commit gets to the stable tree and that blows up? That is
something that is something inherent when relying on AI and
aplies-it-must-be-ok workflow.
The issue I see here is that there's no way to validate the patches that
go in mm/. I'd happily run whatever test suite you use to validate these
patches, but it doesn't exist.
I can run xfstests for fs/, I can run blktests for block/, I can run
kselftests for quite a few other subsystems in the kernel. What can I
run for mm?
I'd be happy to run whatever validation/regression suite for mm/ you
would suggest.
I've heard the "every patch is a snowflake" story quite a few times, and
I understand that most mm/ patches are complex, but we agree that
manually testing every patch isn't scalable, right? Even for patches
that mm/ tags for stable, are they actually tested on every stable tree?
How is it different from the "aplies-it-must-be-ok workflow"?
--
Thanks,
Sasha
