On Sun, Oct 16, 2022 at 9:43 AM Prarit Bhargava <prarit@xxxxxxxxxx> wrote:
>
> Hey ptalbert and jforbes,
>
> I'm writing a script that will automate some of the CS9/RHEL CONFIG reviews.
>
> One thing I'm doing in the script is comparing the CS9/RHEL CONFIG value
> to the ARK value. If they match then the scripts passes. If they don't
> match then the script finds all "similar" ARK CONFIG values and displays
> their value.
>
> For example (sorry for the crappy formatting in email),
>
> A CONFIG change in RHEL commit 1df606e96b65 ("rehdat/configs: set
> missing options relevant to CXL update") does not match ARK.
> An ARK MR should be opened to make this change in the ARK repository.
> Take care to confirm arch-specific and fedora/ark/common changes.
> RHEL: ./redhat/configs/ark/generic/CONFIG_PROVE_CXL_LOCKING:#
> CONFIG_PROVE_CXL_LOCKING is not set
> ARK : ./redhat/configs/ark/generic/CONFIG_PROVE_CXL_LOCKING does
> not exist.
> Here are some CONFIG files in ARK that might match:
> ./redhat/configs/common/generic/CONFIG_PROVE_CXL_LOCKING:#
> CONFIG_PROVE_CXL_LOCKING is not set
>
> ./redhat/configs/fedora/generic/arm/armv7/CONFIG_PROVE_CXL_LOCKING:CONFIG_PROVE_CXL_LOCKING=y
>
> ./redhat/configs/fedora/generic/s390x/CONFIG_PROVE_CXL_LOCKING:CONFIG_PROVE_CXL_LOCKING=y
>
> Note I'm still working on the wording of "An ARK MR should be opened to
> make this change in the ARK repository." as the issue really may be the
> RHEL/CS9 MR.
>
> In any case, an interesting warning is when the ARK CONFIG is in one of
> the pending directories, for example,
>
> A CONFIG change in RHEL commit 33b6bfac97e1 ("RHEL: ALSA: update
> configuration") does not match ARK.
> An ARK MR should be opened to make this change in the ARK repository.
> Take care to confirm arch-specific and fedora/ark/common changes.
> RHEL: ./redhat/configs/common/generic/CONFIG_SND_SOC_TAS2780:#
> CONFIG_SND_SOC_TAS2780 is not set
> ARK : ./redhat/configs/common/generic/CONFIG_SND_SOC_TAS2780 does
> not exist.
> Here are some CONFIG files in ARK that might match:
>
> ./redhat/configs/fedora/generic/CONFIG_SND_SOC_TAS2780:CONFIG_SND_SOC_TAS2780=m
> ./redhat/configs/pending-ark/generic/CONFIG_SND_SOC_TAS2780:#
> Symbol: SND_SOC_TAS2780 [=n]
> ./redhat/configs/pending-ark/generic/CONFIG_SND_SOC_TAS2780:# Type
> : tristate
> ./redhat/configs/pending-ark/generic/CONFIG_SND_SOC_TAS2780:#
> Defined at sound/soc/codecs/Kconfig:1539
> ./redhat/configs/pending-ark/generic/CONFIG_SND_SOC_TAS2780:#
> Prompt: Texas Instruments TAS2780 Mono Audio amplifier
> ./redhat/configs/pending-ark/generic/CONFIG_SND_SOC_TAS2780:#
> Depends on: SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && I2C [=y]
> ./redhat/configs/pending-ark/generic/CONFIG_SND_SOC_TAS2780:#
> Location:
> ./redhat/configs/pending-ark/generic/CONFIG_SND_SOC_TAS2780:#
> Main menu
> ./redhat/configs/pending-ark/generic/CONFIG_SND_SOC_TAS2780:#
> -> Device Drivers
> ./redhat/configs/pending-ark/generic/CONFIG_SND_SOC_TAS2780:#
> -> Sound card support (SOUND [=m])
> ./redhat/configs/pending-ark/generic/CONFIG_SND_SOC_TAS2780:#
> -> Advanced Linux Sound Architecture (SND [=m])
> ./redhat/configs/pending-ark/generic/CONFIG_SND_SOC_TAS2780:#
> -> ALSA for SoC audio support (SND_SOC [=m])
> ./redhat/configs/pending-ark/generic/CONFIG_SND_SOC_TAS2780:#
> -> CODEC drivers
> ./redhat/configs/pending-ark/generic/CONFIG_SND_SOC_TAS2780:#
> Implied by [n]:
> ./redhat/configs/pending-ark/generic/CONFIG_SND_SOC_TAS2780:# -
> SND_SOC_ALL_CODECS [=n] && SOUND [=m] && !UML && SND [=m] && SND_SOC
> [=m] && COMPILE_TEST [=n]
> ./redhat/configs/pending-ark/generic/CONFIG_SND_SOC_TAS2780:#
> ./redhat/configs/pending-ark/generic/CONFIG_SND_SOC_TAS2780:#
> ./redhat/configs/pending-ark/generic/CONFIG_SND_SOC_TAS2780:#
> ./redhat/configs/pending-ark/generic/CONFIG_SND_SOC_TAS2780:#
> CONFIG_SND_SOC_TAS2780 is not set
>
> I was hoping to code the script to say something like "A similar CONFIG
> has been found in pending-ark. You can review this change by viewing
> ARK MR xxx".
>
> The problem I'm having is determining xxx :)
What you are describing is such a rare event, that I am not sure it is
worth scripting. The SND_SOC in pending stood there for too long
because of a script failure to create the MR itself during the 6.0
merge window. We did not notice it until the 6.0 cycle was over. We
have seen such script failures on average, less than once per year.
By rules, provided no similar script failures, no config item should
be in pending by the time it is in a released kernel. In practice, a
large number of those MRs are acked and merged long before the
released kernel phase, and we are simply chasing down a few stragglers
by rc5 or so. And now that we are more aware of the possibility of a
script failure in that particular place, I will be on the lookout for
them as well to ensure that they don't go beyond a single cycle.
> Any ideas on how to do that? I suppose I could go through all the open
> ARK MRs and find it but that seems wasteful. Is there a possibility of
> adding a link to the ARK MR to the CONFIG file? That might be generally
> useful for anyone who wants to review it.
While this does sound useful, it means we must create the commits,
push to create an MR, then immediately go back and edit the commits
because we have an MR number now. This link would be short lived as
it would go away once out of pending (or a number of other scripts get
unhappy). At the height of the upstream cycle, we tend to have less
than 50 config MRs open for things in pending. It seems just as easy
to search it.
> P.
> _______________________________________________
> kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________
kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
