On 15.05.23 09:46, Geert Uytterhoeven wrote: > On Sun, May 14, 2023 at 1:01 PM Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote: >> On 10/05/2023 10:05, Mauro Carvalho Chehab wrote: >>> And another CI job testing bisect breakages as I receive pull requests, >>> applying patch per patch and using both allyesconfig and allmodconfig, >>> also on x86_64 arch with W=1: >>> >>> https://builder.linuxtv.org/job/patchwork/ >>> >>> The rule is to not merge stuff on media tree if any of those jobs >>> fail. I also fast-forward merging patches whose subject states that >>> the build has failed. >>> >>> In order to help with that, on normal situation, I usually take one week >>> to merge stuff from media_stage into media_tree, doing rebases at >>> media_stage if needed to avoid git bisect build breakages at media_tree >>> (which is from where I send my update PRs to you). >>> >>> Unfortunately, currently we don't have resources to do multiple randconfig >> >> Is you media staging tree included in LKP (kernel test robot)? You would >> get huge build coverage after every push to your staging repo. > > As (multiple[*[) fixes for the build issues were submitted before the > opening of the merge window, there must have been some build coverage, > with even some people acting upon it... > > [*] General note, not limited to media: please apply build fixes and > regression fixes ASAP, to avoid multiple people running into the > same issues, and spending time on bisecting, investigating, > fixing, ... > Thanks a lot! FWIW, I proposed a rewritten section of Documentation/process/handling-regressions.rst that is closely related to this. The new text says: ``` + * Do not consider regressions from the current cycle as something that can wait + till the end of the cycle, as the issue might discourage or prevent users and + CI systems from testing mainline now or generally. [...] + * Aim to mainline a fix within two or three days, if the issue is severe or + bothering many users -- either in general or in prevalent conditions like a + particular hardware environment, distribution, or stable/longterm series.``` For details and context see https://lore.kernel.org/linux-doc/6971680941a5b7b9cb0c2839c75b5cc4ddb2d162.1684139586.git.linux@xxxxxxxxxxxxx/ Let me known if you think I should be more explicit; I could simply add a "this includes, but is not limited to fixes for build errors" to the second segment mentioned above. But well, that yet again would make the text longer. :-( Ciao, Thorsten
