On Fri, Apr 08, 2022 at 11:29:33AM +0300, Alexey Khoroshilov wrote:
On 30.03.2022 07:36, Greg Kroah-Hartman wrote:
On Wed, Mar 30, 2022 at 02:49:00AM +0300, Alexey Khoroshilov wrote:
Dear Greg,
First of all, thank you very much for keeping stable maintenance so well.
We (Linux Verification Center of ISPRAS (linuxtesting.org)) are going to join a team of regular testers for releases in 5.10 stable branch (and other branches later). We are deploying some test automation for that and have met an oddity that would to discuss.
Sometimes, like in 5.10.109 release, we have a situation when a released version (5.10.109) differs from the release candidate (5.10.109-rс1). In this case there was a patch "llc: only change llc->dev when bind()succeeds" added to fix a bug in another llc fix. Unfortunately, as Pavel noted, this patch does not fix a bug, but introduces a new one, because another commit b37a46683739 ("netdevice: add the case if dev is NULL") was missed in 5.10 branch.
This happens quite frequently due to issues found in testing. It's not a new thing.
The problem will be fixed in 5.10.110, but we still have a couple oddities:
we have a release that should not be recommended for use
we have a commit message misleading users when says:
Tested-by: Pavel Machek (CIP) pavel@denx.de Tested-by: Fox Chen foxhlchen@gmail.com Tested-by: Florian Fainelli f.fainelli@gmail.com Tested-by: Shuah Khan skhan@linuxfoundation.org Tested-by: Bagas Sanjaya bagasdotme@gmail.com Tested-by: Salvatore Bonaccorso carnil@debian.org Tested-by: Linux Kernel Functional Testing lkft@linaro.org Tested-by: Sudip Mukherjee sudip.mukherjee@codethink.co.uk Tested-by: Guenter Roeck linux@roeck-us.net
but actually nobody tested that version.
There are potential modifications in stable release process that can prevent such problems:
(1) to always release rс2 when there are changes in rc1 introduced
(2) to avoid Tested-by: section from release commits in such situations.
Or may be it is overkill and it too complicates maintenance work to be worth. What do you think?
I think it's not worth the extra work on my side for this given the already large workload. What would benifit from this to justify it?
I see, thank you.
I believed the goal is to provide some minimal quality guarantees for a particular version of the code.
I do not understand what you mean by this. Can you please explain?
But if the process of updates is quite intensive, it may make sense to transfer responsibility for particular release verification downstream.
There is no need to transfer anything as per the license of the kernel, right?
I do not understand what you are trying to do here. Can you provide details please?
thanks,
greg k-h