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 05064522F for ; Thu, 13 Jun 2024 10:18:13 +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=1718273896; cv=none; b=HeK1+0szr77nW0OFF8hGMqtQCBqJ6DhVWhqJpihOTaz2ATVA8Isyr0kmamGKvnr28HDWY804//eNZ4JQXzPh6aqfohF/uYCt4n+Axe/EPpNzEgmHGfTNg9u4CvO7LHYreZVwrMSDTOT2OEp3FB8QTzxVDLw2bNiq0KMMhA9l6Kg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718273896; c=relaxed/simple; bh=cU5GIffJ211u6Lttb3b1Jj8ktnwsBAMYNzOQbp9FInk=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=T6/T90tKRBWHMQbMumfby1AsgeOVP0MuWitYBWdWXEX9h2dnTQz5xzbAM4vlWv4c5fOXfU5y9nvNOC6XmlcezPeyn3l48Z78QqA67MUA3CKHnXyB/hPlBEMxP0Df/IRIaF+WZOyqQEAEjg9FZ6NUb0EozmetoeSyGb9eCFHt658= 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=zyPoSobx; 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="zyPoSobx" 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=TEWEYts/T7Eghdkegd3MBulU5ow74SK2cV9SZ6V1dNo=; t=1718273894; x=1718705894; b=zyPoSobx8CPZ4xN2VVrwffBPmp75ijEFsUdPdNjB+Kj1VBzsT4BSWqfVvTAcG w71MzjCcsTmfEoFWy52R5JHmwFksSXuhC44I5kiAuuSAAUKTtLZFcDKZK+d+FskGHtqHpImSNkLis vMchLfKMsbHKqUhA47xgJzHcPdJ5lGZqPPsGscJT04BbIbEkJ88lBbBOZCRVqmcxN77Yt0janqSW8 rTtq9tnbbcPkrpq1oF0iuHpNj9tDWBRCCaaVQWn82/0IU1jMXMeGrJPnLuaACYp5hVboV/QMMQHVM 5oxLahH3es5uPjIankHSpaIXzv7kh5QvxXhagkUaGxDgkb9F1w==; 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 1sHhWw-0002he-Gg; Thu, 13 Jun 2024 12:18:06 +0200 Message-ID: Date: Thu, 13 Jun 2024 12:18:06 +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: Jan Kara Cc: "ksummit@lists.linux.dev" References: <20240613095917.eeplayyfvl6un56y@quack3> 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: <20240613095917.eeplayyfvl6un56y@quack3> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-bounce-key: webpack.hosteurope.de;linux@leemhuis.info;1718273894;15b028f0; X-HE-SMSGID: 1sHhWw-0002he-Gg On 13.06.24 11:59, Jan Kara wrote: > On Thu 13-06-24 10:42:01, Thorsten Leemhuis wrote: >> * One cause of regressions that happen in stable trees (and not in >> mainline) I've seen quite a few times are backports of commits with >> Fixes: tags that were part of a patch-series and depend on earlier >> patches from the series. The stable-team afaics has no easy way to spot >> this, as there is no way to check "was this change part of a series". >> Sometimes I wonder if a dedicated tag linking to the submission of a >> patch could help -- and is something quite a few maintainers already >> really want and add using a "Link" tag despite Linus dislike for that >> (IIRC). > > FWIW I (and a few other maintainers) use 'Message-Id' tag to link to > submission. This is still easily convertible to lore link and unlike 'Link' > tag it is clear what this tag is about and that it is not just a link to > related discussion or something like that. AFAIK this also addresses Linus' > dislike because what he was complaining about is that 'Link' should be > linking to some useful context for the changelog, not just patch > submission. Well, I fine with me. But at the same time this makes me wonder: if we want to establish a new tag, why not just use something that makes it more obvious what the tag is about (e.g. "Review:", "Posting:", "Submission:", or something like that) and then just use a lore link for consistency, as we deal with those already all the time? Also makes it easier to follow later for anyone that looks closer at the commit and wants the bigger picture (e.g. cover letter and a list of related patches). >> But following that link for each and every patch slated for >> backporting does not scale for the stable team anyway, so it's likely >> not worth it. > > Well, what I'd propose is that if 'Message-Id' tag is present and thus it > can be established (in an automated way using lore) which series this patch > was part of, then stable maintainers will either pick all patches from the > start of the series upto this change or nothing. +1 (and this obviously could work about the same if it was a proper link) > Because what I see > happening several times in a year just in subsystems I maintain is that > stable tree picks up more or less random subset of a patch series > (depending on what applies and what their algorithms decide to take) and > that causes issues. Sometimes we catch that during glancing over patches > flowing into stable (like Amir did last week) but sometimes we don't and > breakage happens. > > This will require a bit more discipline when creating patch series to put > more or less independent fixes that should go into stable first but that is > a good practice anyway and mostly followed at least in the areas of the > kernel I work in. +1 Ciao, Thorsten