From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 1A1C6383C84 for ; Tue, 2 Jun 2026 16:51:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780419082; cv=none; b=ctuxWcAeMznhYovir+BQ3Pu3AbcnSnFCScne71T70iaffg32af9Ai8AfXO26gkIsxnYiyVyVozIlqL09xKY6e88+RKc4r71Tpl8veJtMx5X/R/QWz0WFIwN2qHJOALcpik7ONSPdoDsZNLVXB0Q1nxPhwKxaOX9Gm1oS0kpKL9Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780419082; c=relaxed/simple; bh=iSAy6Y1ZMC4+to5uHDxjV23TWdSBDKYUM64Prkj5ggs=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=raU0CKGDCVMaaPUvKSQvHhkjLCfI4Mm6TPKUc3tjQ09+5t4JOAjr+Rm+NQpdePCmLrDrOZ59qBnuMd+q1eK718InWWibtnZuvBfFEQMno+y7caJ+n/81AsGoL+WVWblf9TgeNhytqXs18SYUWflubxuQXhPWKCrO6G8/Ap9vODc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=I9j+ChfK; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="I9j+ChfK" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3FD791F00893; Tue, 2 Jun 2026 16:51:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780419080; bh=9WHTiY1N2Z1J0iSMC0yEDaCXwrHu3OAAebVGabMf4Vw=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=I9j+ChfKGgLiq2i3Uk+0Q1tNiLvTfaT/oo+INbdu5jgNdD5GBqPzahUTWgjoDH4uf yCOPU1cDrN9La22WZnch7puYj4IaFt5rzADqA3ME8WHkA37ETC93RAAcL84uL4kbkN m0I0dWitfhWXaXR7kpasAw0T9acmnLHY5PIN/+zTHL10Y01S2Q45KB3lqdNJjMp8Wx gZQlqS2NdxapCTCqU6Jljk90EMeySIhfqqPJ8U4WusdRLFxQ6BEtzVcOxLTpGStIDf cEYVnrLpijfXxSiyt+qgVCZJVBtUHETDsPe64lM7RicdebTCkiRf/ASf+L/SiISJZr XMTk8rTk5uGew== Date: Tue, 2 Jun 2026 18:51:15 +0200 From: Mauro Carvalho Chehab To: Derek Barbosa Cc: Roman Gushchin , Konstantin Ryabitsev , Jason Gunthorpe , Steven Rostedt , users@kernel.org, Linux Media Mailing List Subject: Re: Linking Patchwork with Sashiko? Message-ID: <20260602185115.4b5c4886@foz.lan> In-Reply-To: References: <20260530103004.6fe2ffa7@foz.lan> <7E971C76-0568-43EF-9EE7-C8DB78C45CA1@linux.dev> <20260530200017.0fe7f685@foz.lan> <20260530204945.22ac92c6@foz.lan> <20260530205351.19847fc8@foz.lan> X-Mailer: Claws Mail 4.4.0 (GTK 3.24.52; x86_64-redhat-linux-gnu) Precedence: bulk X-Mailing-List: linux-media@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Tue, 2 Jun 2026 11:51:42 -0400 Derek Barbosa wrote: > On Sat, May 30, 2026 at 08:53:51PM +0200, Mauro Carvalho Chehab wrote: > > > > In time: problematic in the sense that the first project that > > picked it is likely the patch "owner": the token will require > > maintainership on such project. > > > > In practice it would mean that the token used on patchwork instances > > with multiple Kernel projects may need maintainers permission on all > > such projects, as otherwise patchwork update will fail. > > > > Thanks, > > Mauro > > > > Hi Mauro, > > Just to recap the the thread, to confirm that I am following it correctly: > > - Patchwork only supports a single URL mask for message-ID lookup (lore or > sashiko). Adding a sashiko link would require diverging from upstream. Not sure what you mean. AFAIKT, a RFC-822 application can have just one message-ID per message. For message lookup, patchwork works using its own patch ID, or via a search to the original message ID that contains the patch. So, no, it won't be lore nor sashiko, as neither lore nor sashiko write e-mails ;-) If you're talking instead about CI reports, patchwork does support multiple sources. See for instance: https://patchwork.linuxtv.org/project/linux-media/patch/20260531-qcom-cphy-v5-8-6be0f62b4d65@ixit.cz/ There, media-ci does update it directly via rest protocol; Sashiko (and LKP/Sysbot) messages are handled by inspecting e-mails using pw_tools. > - pw_tools is a workaround solution to get/set status on patchwork via bot-mail > parsing. pw tokens also have broad permission scope. pw_tools is not a workaround solution. It is client tools implementing Patchwork's REST protocol. You can use it or whatever other client you want. If you decide using it, feel free to send me patches improving it as needed. > which that leaves us with two "methods" of integration: > > 1. The Sashiko daemon calls the pw_tools script directly to update the status. > 2. Sashiko sends a single-per-patch-email with parseable "status" to a mailing > list, where some running daemon will pickup the mail. > > please correct me if I am wrong here :) There is a third option, which is what I currently implemented at: https://patchwork.linuxtv.org/project/linux-media/list/ 3. Parse the e-mails already sent by Sashiko, before/after patchwork's e-mail job process. The problem with (3) is that it will only pick Sashiko's warning e-mails, as success doesn't generate e-mails. The alternative of sending e-mails also for success doesn't scale, as nobody wants that every possible bot out would send success messages to them. Those are OK to just update CI context display. That's why, on media, we do prefer (2), preferably sending e-mails to a separate e-mail that won't be adding it to the mailing list. > Roman, for 1, do we want to dip our toes into FFI for the provided pw_tools > python script, or would a more general std::process::* subprocess suffice? > > Alternatively, we could just translate the logic into Rust, gated behind a > config. I will have to think about how we would like to implement retry-queues. Certainly if you decide to do that, you'll need to have retry-queues and eventually some traffic-flow control to avoid too heavy workloads at patchwork's side. > Thinking out loud: would it be simpler to "tag" the reviews that require a > patchwork-status-update in the DB, and let a cronjob handle setting patchwork > state? updating the candidates that have successfully posted? Patchwork handles e-mail sending this way. > Anyway, Mauro, I think we have the capacity to tackle both patchwork integration > methods. Would exposing a configuration in the email_policy file that allowed > for mailing lists to specify what type of patchwork integration suffice? > > This way, a mailing list that would want patchwork integration can opt for > either the single email approach (as you described) or through the API? Makes sense. > something like: > > [subsystems.linux-media] > lists = ["linux-media@vger.kernel.org"] > reply_to_author = true > cc = ["linux-media@vger.kernel.org"] > + # optional value can be set to email or API > + patchwork = "email" works for me, but I would, instead do something like this: patchwork = "email:a-bot-status-update-email@linuxtv.org" to let one specify a different e-mail address to handle context updates, thus reducing ML traffic. > Roman is currently working through how "subsystems" are detected via Sashiko, > taking inspiration from the get_maintainer.pl script. You could also take a look at: Documentation/sphinx/maintainers_include.py The parser there converts maintainer entries into a dict, which can make it easier to use, specially when you want to handle multiple subsystems. > This may help with some of > the concerns I saw with patches-meant-for-other mailing lists? Yes. Btw, in the specific case of projects using patchwork@kernel.org (or any other instance with multiple Kernel projects), the user which updates CI status information has to be maintainer on *all* kernel projects, as otherwise some/several patches won't be updated. Basically, when a message is c/c to multiple mailing lists, just one of such mailing list will "own" the patch. Only a Django user with permission at the owner list can update it. Thanks, Mauro