Re: fixing sashiko failure to apply (was Re: [PATCH v5 00/16] mm/rmap: index MAP_PRIVATE file-backed folios by anonymous pgoff)

[Zi Yan]

<snip>
>> >>
>> >>>>
>> >>>> Sashiko can be guided with a base-commit: tag but I'm not sure how to
>> >>>> tell it what tree/branch to try, or even if that's necessary.  Perhaps
>> >>>> someone can figure this out sometime.
>> >>>
>> >>> b4 gives a base commit, but I think because the trees are rebased it ends
>> >>> up being the incorrect one.
>> >>>
>> >>> Not sure what the solution is!
>> >>>
>> >>
>> >> We have seen this on the Xe list (our list is based on drm-tip),
>> >> typically with cross-subsystem patches. Some cross-subsystem patches
>> >> apply and run correctly, while others do not but public CI flows run
>> >> based on drm-tip. I do not have a bisect or a clear understanding of
>> >> what works and what doesn't, but I think it would be very useful if the
>> >> community could better understand the root cause.
>> >
>> > As Mike said, mm-unstable/mm-new is heavily rebased and also carries the old
>> > version of the series before the new one is applied, so it's super unclear what
>> > the base commit should be there.
>> >
>> > But in general, I wonder if it's possible that we could tell sashiko
>> > after-the-fact what base commit to look at once the series is in, or re-trigger
>> > it somehow once it's in-tree?
>> >
>> > Roman - any suggestions on what we could do to help sashiko find things?
>> >
>> > (Once mm-next is in place everything with change again, but can address that
>> > then :)
>>
>> I can implement any reasonable logic here, the problem is that my understanding is
>> the current mm process is a bit vague here. Which likely will be also an issue for the mm ci.
>> I’ll merge a support for b4-like dependencies specification soon.
>
> Yeah I suspect things might be tricky with mm given the rebases honestly.
>
>>
>> Re re-starting with manual selection it’s on my todo list, but maybe a bit lfurther away, as it requires
>> an authorization, etc.
>
> Yeah that's the fly in the ointment I guess for many things like giving instant
> feedback on accuracy, well you want to make sure the person giving it is who you
> think they are :)
>
> Probably an email -> author with magic link or something but thinking through
> how to avoid abuse/spam/rate limiting everything etc. is surely all a pain :)

If b4 is used, the cover letter comes with a fixed change-id. That can
be a good id for new patch series replacement. For patches do not use
b4, authors can add their own change-id. Without change-id, if the new
version comes with a link to the prior version, that can be helpful too.
If none is present, author email + patch title might be the last resort.
But I think we need to encourage authors to provide some id for their
patches to make replacement easier instead of spending too much effort
on identifying different patch versions.

-- 
Best Regards,
Yan, Zi