Messages in this thread | | | Date | Fri, 8 Apr 2022 13:24:32 +0200 | From | Greg Kroah-Hartman <> | Subject | Re: Stable release process proposal (Was: Linux 5.10.109) |
| |
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
| |