From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-181.mta1.migadu.com (out-181.mta1.migadu.com [95.215.58.181]) (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 B3135357D0F for ; Tue, 2 Jun 2026 20:13:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.181 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780431230; cv=none; b=KSq+zQyVUFmlD+NfRlP1PHEXacE9pOF0Ggfio/+YJJ0daOX+Ra28wt/57GIlSf5HK+htJ4muI+Qjk4y2Z/aRBfnEYA3v7UyrLDi6S7tWLIGEACAksdjjRA3NVodU4UZ7PRZCsiU2j1CKvSy4eraNpERUkLwNQcODLPINTAE2uzs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780431230; c=relaxed/simple; bh=40D6XnayS1rVeYAEcUfX0I+cg2ZKhBBkf/t4KTWvyP8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=OqUyBylXHq9f1yCIJ3YXUezqopcvc++vggxtoJuHMi8a3TAVkZDkZMclQ4NCJ7+fHJQG2SOBV7ffIC45uzOP3NKUC/9xtvcLAWkhZe+is0zi2qExBdYH6hPi8+hTBLQ4ELMYAj0GM4QnPdXZzbZ7Kp6xK3VlgWa8LwDSS5GixCc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=P7+BLpcf; arc=none smtp.client-ip=95.215.58.181 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="P7+BLpcf" X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1780431227; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=qUDrOvJb5XL1UwmKCUAHNSX0L/sIhgTofGvh/5nroP4=; b=P7+BLpcfL1NcIoMoTA/X8hVwBJb+7aky2xlv6Pl7La1z+CMY8EyBiyOHWTmMp8fUntowxK 0yVD+f1812PgwZHJ983IM7rR8eZRoC1jEqZ7+i/2YRjqaChnZqJaQAfbmUWYZ6i3SvMpRo cuI6fHvMPRe8occRVeHOWR0YFlTCqgE= From: Roman Gushchin To: Derek Barbosa Cc: Mauro Carvalho Chehab , Konstantin Ryabitsev , Jason Gunthorpe , Steven Rostedt , users@kernel.org, Linux Media Mailing List Subject: Re: Linking Patchwork with Sashiko? In-Reply-To: (Derek Barbosa's message of "Tue, 2 Jun 2026 11:51:42 -0400") References: <20260530103004.6fe2ffa7@foz.lan> <7E971C76-0568-43EF-9EE7-C8DB78C45CA1@linux.dev> <20260530200017.0fe7f685@foz.lan> <20260530204945.22ac92c6@foz.lan> <20260530205351.19847fc8@foz.lan> Date: Tue, 02 Jun 2026 20:13:15 +0000 Message-ID: <7ia4tsrkn1k4.fsf@castle.c.googlers.com> Precedence: bulk X-Mailing-List: linux-media@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain X-Migadu-Flow: FLOW_OUT Derek Barbosa writes: > 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. Is it something we can change upstream? > > - pw_tools is a workaround solution to get/set status on patchwork via bot-mail > parsing. pw tokens also have broad permission scope. > > 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. This feels a bit hacky. > please correct me if I am wrong here :) > > 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. I strongly prefer the option with implementing the logic in Rust. > 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? We have already a well working logic for sending emails, we can more or less duplicate it for patchwork. Thanks