From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from wp530.webpack.hosteurope.de (wp530.webpack.hosteurope.de [80.237.130.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C50AE158D9A for ; Tue, 18 Jun 2024 13:13:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=80.237.130.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718716385; cv=none; b=e1qYHrMYhEoG702kwSjYVCIYezimaJpJzdVDfFDCcptiwyNx6QeyETgooowdYGMJGCCcYde3N61ocoV/FRi3fxKzPLoFeDbtQQeIw9OpaO78KDLPWxs4UnoVIGUbi6jVlnfynsb/WaiPvZ0YDae6/F2Zcsn0PE/ywEmgqAMLMD8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718716385; c=relaxed/simple; bh=PyLHxTY4c0CrMvevzwZbpbJME70u1iIGBTEh7r4UdVc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Oa5VJlUNejbZ/45D02AOBRXKrP26NR7MRefvlQGcL+uVdmIaEbhv0alZcnw4Pj0BPgo7i2czp2Il8Es1/j8DQdqLR9Ipto9h5N+CoifWbRRiH+2Ki1oiXR3txfoawmTw68MM1NK8BJ8OSWuwRmQ/rQEb1MvUtw1sSScBXLyeB+Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=leemhuis.info; spf=pass smtp.mailfrom=leemhuis.info; dkim=pass (2048-bit key) header.d=leemhuis.info header.i=@leemhuis.info header.b=nB3suKix; arc=none smtp.client-ip=80.237.130.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=leemhuis.info Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=leemhuis.info Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=leemhuis.info header.i=@leemhuis.info header.b="nB3suKix" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=leemhuis.info; s=he214686; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date:Message-ID:From: Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:In-Reply-To: References; bh=TFgTZN8C4tB2qCCLJWkbE/qxBlxRrNp/hKX11L6qFus=; t=1718716383; x=1719148383; b=nB3suKixn7gD5u0mOwUQBZVHO4wlt7v7xe/QGV/m/cv9Z977WwkhRHGtiNg/T hs+exJ0ehJdxhOgKB76Do1pcXf0IjUj/n1cVp4emY4/VqumnD3ThlqwwFo+Wmy/TuiAjwaTnGsvkz 1Zfo9vpxDz7l00Ga5fK/p7Lqnh1dmJSMmEJ+OHOQgi+xbBJV6YwuXU/sVYLIvO0C6GEIzjVgNhOp2 tDmTj1U7nzK32Fw9dwatsN9hGAa7UaiTg/Th2CFmOxvHAhXGxZZcdzS+a9s6ihyLfziBkZy4T2hWv UVjj9WGezmkTOABCTu3wM8fdp6qzPd2PjaG0LGAahIRYuxYLqg==; Received: from [2a02:8108:8980:2478:8cde:aa2c:f324:937e]; authenticated by wp530.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1sJYdx-0006Qi-Uv; Tue, 18 Jun 2024 15:13:02 +0200 Message-ID: Date: Tue, 18 Jun 2024 15:12:59 +0200 Precedence: bulk X-Mailing-List: ksummit@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [MAINTAINERS SUMMIT] [4/4] Discuss how to better prevent backports of commits that turn out to cause regressions To: Sasha Levin Cc: "ksummit@lists.linux.dev" References: From: Thorsten Leemhuis Content-Language: en-US, de-DE Autocrypt: addr=linux@leemhuis.info; keydata= xsFNBFJ4AQ0BEADCz16x4kl/YGBegAsYXJMjFRi3QOr2YMmcNuu1fdsi3XnM+xMRaukWby47 JcsZYLDKRHTQ/Lalw9L1HI3NRwK+9ayjg31wFdekgsuPbu4x5RGDIfyNpd378Upa8SUmvHik apCnzsxPTEE4Z2KUxBIwTvg+snEjgZ03EIQEi5cKmnlaUynNqv3xaGstx5jMCEnR2X54rH8j QPvo2l5/79Po58f6DhxV2RrOrOjQIQcPZ6kUqwLi6EQOi92NS9Uy6jbZcrMqPIRqJZ/tTKIR OLWsEjNrc3PMcve+NmORiEgLFclN8kHbPl1tLo4M5jN9xmsa0OZv3M0katqW8kC1hzR7mhz+ Rv4MgnbkPDDO086HjQBlS6Zzo49fQB2JErs5nZ0mwkqlETu6emhxneAMcc67+ZtTeUj54K2y Iu8kk6ghaUAfgMqkdIzeSfhO8eURMhvwzSpsqhUs7pIj4u0TPN8OFAvxE/3adoUwMaB+/plk sNe9RsHHPV+7LGADZ6OzOWWftk34QLTVTcz02bGyxLNIkhY+vIJpZWX9UrfGdHSiyYThHCIy /dLz95b9EG+1tbCIyNynr9TjIOmtLOk7ssB3kL3XQGgmdQ+rJ3zckJUQapLKP2YfBi+8P1iP rKkYtbWk0u/FmCbxcBA31KqXQZoR4cd1PJ1PDCe7/DxeoYMVuwARAQABzSdUaG9yc3RlbiBM ZWVtaHVpcyA8bGludXhAbGVlbWh1aXMuaW5mbz7CwZQEEwEKAD4CGwMFCwkIBwMFFQoJCAsF FgIDAQACHgECF4AWIQSoq8a+lZZX4oPULXVytubvTFg9LQUCX31PIwUJFmtPkwAKCRBytubv TFg9LWsyD/4t3g4i2YVp8RoKAcOut0AZ7/uLSqlm8Jcbb+LeeuzjY9T3mQ4ZX8cybc1jRlsL JMYL8GD3a53/+bXCDdk2HhQKUwBJ9PUDbfWa2E/pnqeJeX6naLn1LtMJ78G9gPeG81dX5Yq+ g/2bLXyWefpejlaefaM0GviCt00kG4R/mJJpHPKIPxPbOPY2REzWPoHXJpi7vTOA2R8HrFg/ QJbnA25W55DzoxlRb/nGZYG4iQ+2Eplkweq3s3tN88MxzNpsxZp475RmzgcmQpUtKND7Pw+8 zTDPmEzkHcUChMEmrhgWc2OCuAu3/ezsw7RnWV0k9Pl5AGROaDqvARUtopQ3yEDAdV6eil2z TvbrokZQca2808v2rYO3TtvtRMtmW/M/yyR233G/JSNos4lODkCwd16GKjERYj+sJsW4/hoZ RQiJQBxjnYr+p26JEvghLE1BMnTK24i88Oo8v+AngR6JBxwH7wFuEIIuLCB9Aagb+TKsf+0c HbQaHZj+wSY5FwgKi6psJxvMxpRpLqPsgl+awFPHARktdPtMzSa+kWMhXC4rJahBC5eEjNmP i23DaFWm8BE9LNjdG8Yl5hl7Zx0mwtnQas7+z6XymGuhNXCOevXVEqm1E42fptYMNiANmrpA OKRF+BHOreakveezlpOz8OtUhsew9b/BsAHXBCEEOuuUg87BTQRSeAENARAAzu/3satWzly6 +Lqi5dTFS9+hKvFMtdRb/vW4o9CQsMqL2BJGoE4uXvy3cancvcyodzTXCUxbesNP779JqeHy s7WkF2mtLVX2lnyXSUBm/ONwasuK7KLz8qusseUssvjJPDdw8mRLAWvjcsYsZ0qgIU6kBbvY ckUWkbJj/0kuQCmmulRMcaQRrRYrk7ZdUOjaYmjKR+UJHljxLgeregyiXulRJxCphP5migoy ioa1eset8iF9fhb+YWY16X1I3TnucVCiXixzxwn3uwiVGg28n+vdfZ5lackCOj6iK4+lfzld z4NfIXK+8/R1wD9yOj1rr3OsjDqOaugoMxgEFOiwhQDiJlRKVaDbfmC1G5N1YfQIn90znEYc M7+Sp8Rc5RUgN5yfuwyicifIJQCtiWgjF8ttcIEuKg0TmGb6HQHAtGaBXKyXGQulD1CmBHIW zg7bGge5R66hdbq1BiMX5Qdk/o3Sr2OLCrxWhqMdreJFLzboEc0S13BCxVglnPqdv5sd7veb 0az5LGS6zyVTdTbuPUu4C1ZbstPbuCBwSwe3ERpvpmdIzHtIK4G9iGIR3Seo0oWOzQvkFn8m 2k6H2/Delz9IcHEefSe5u0GjIA18bZEt7R2k8CMZ84vpyWOchgwXK2DNXAOzq4zwV8W4TiYi FiIVXfSj185vCpuE7j0ugp0AEQEAAcLBfAQYAQoAJgIbDBYhBKirxr6Vllfig9QtdXK25u9M WD0tBQJffU8wBQkWa0+jAAoJEHK25u9MWD0tv+0P/A47x8r+hekpuF2KvPpGi3M6rFpdPfeO RpIGkjQWk5M+oF0YH3vtb0+92J7LKfJwv7GIy2PZO2svVnIeCOvXzEM/7G1n5zmNMYGZkSyf x9dnNCjNl10CmuTYud7zsd3cXDku0T+Ow5Dhnk6l4bbJSYzFEbz3B8zMZGrs9EhqNzTLTZ8S Mznmtkxcbb3f/o5SW9NhH60mQ23bB3bBbX1wUQAmMjaDQ/Nt5oHWHN0/6wLyF4lStBGCKN9a TLp6E3100BuTCUCrQf9F3kB7BC92VHvobqYmvLTCTcbxFS4JNuT+ZyV+xR5JiV+2g2HwhxWW uC88BtriqL4atyvtuybQT+56IiiU2gszQ+oxR/1Aq+VZHdUeC6lijFiQblqV6EjenJu+pR9A 7EElGPPmYdO1WQbBrmuOrFuO6wQrbo0TbUiaxYWyoM9cA7v7eFyaxgwXBSWKbo/bcAAViqLW ysaCIZqWxrlhHWWmJMvowVMkB92uPVkxs5IMhSxHS4c2PfZ6D5kvrs3URvIc6zyOrgIaHNzR 8AF4PXWPAuZu1oaG/XKwzMqN/Y/AoxWrCFZNHE27E1RrMhDgmyzIzWQTffJsVPDMQqDfLBhV ic3b8Yec+Kn+ExIF5IuLfHkUgIUs83kDGGbV+wM8NtlGmCXmatyavUwNCXMsuI24HPl7gV2h n7RI In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-bounce-key: webpack.hosteurope.de;linux@leemhuis.info;1718716383;a529f7ff; X-HE-SMSGID: 1sJYdx-0006Qi-Uv On 13.06.24 15:40, Sasha Levin wrote: > On Thu, Jun 13, 2024 at 10:42:01AM +0200, Thorsten Leemhuis wrote: >> I would like to discuss how to better prevent backports of mainline >> commits to stable that turn out to cause regressions. > If you can tell us which backports cause regression we promise not to > backport them :) :) FWIW (as you know, but others might not): I sometimes already do when I notice such a problem (of course that only works if the regression is tracked already). But the machinery and workflow for it could definitely be improved on my side; it's on my todo list, but so are many other things. :-/ >> * We could ask the stable team to only backport changes once they have >> been in mainline for a certain time (something like "at the earliest two >> weeks after the change was present in a mainline release or > > We could, but is the net result positive? This also means that fixes for > real issues take longer to get to users. Well, if the fix is that important urgent it should have been merged in the previous cycle and not have waited for the merge window. > It would make sense if most backports cause a regression. Is it the > case? I can't answer that -- and the data I have is likely to incomplete for that, as I don't become aware of all regressions. >> pre-release"?). But to not delay urgent fixes we then would need >> developers to mark the urgent ones somehow. That is likely a hard sell, >> but maybe less so then what the previous point outlined; untangling >> could help here, too. > > I'd argue that even developers don't necessarily know if something is > "urgent" or not. Heck, what does "urgent" mean? There are so many > usecases for the kernel that it's impossible to define what is urgent > and what is not. Yup. :-/ >> * Maybe convince the stable team to consider all commits with just a >> Fixes: tag as "non urgent", if they were merged during a merge window >> with a committer (or author?) date from before the merge window -- and >> then only backport them after -rc4 to ensure they got at least three >> weeks of mainline testing before they are backported. This is imperfect >> and has downsides, but would be relatively simple to realize. > > The tricky part here is that we can't rely on stable tags for importance > determination. Individuals and subsystems simply don't add stable tags > because they don't want to, not because their commits are not important > or urgent. I know, I know. :-( That's why I introduced that section with "few thoughts my brain came up with", as I myself was unsure how to best improve the situation. Ciao, Thorsten