This is not ideal, but while our kconfig keeps being very dynamic, we
very often bump into the following situation:
Author of kernel MR fixes kconfig -> the MR is fine ->
1 week passes and some other kconfig changes get merged ->
we assign to the bot for merge -> CI fails and we're back at the
beginning
This means the authors have to get back to fixing kconfig out of us
being slow. And if we are slow again, the same cycle can repeat, which
has happened in the past. This is frustrating for everybody. Instead,
if we are ready to merge and the merge bot is the committer, just
skip kconfigcheck failures. It means that some options might have to
wait for the next update to be included, but still forces authors to
fix kconfig on each of their own pushes, which is a possible trade-off
to reduce friction.
This should be save to revert the day kconfigcheck starts changing
only occassionally.
Signed-off-by: Pablo Correa Gómez <pabloyoyoista@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/9385>
Aelin