From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [209.51.188.92]) by sourceware.org (Postfix) with ESMTPS id BA5D13856DC1 for ; Wed, 22 Jun 2022 21:30:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BA5D13856DC1 Received: from fencepost.gnu.org ([2001:470:142:3::e]:52610) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o47tD-0001lR-Ha; Wed, 22 Jun 2022 17:27:55 -0400 Received: from gnu.wildebeest.org ([45.83.234.184]:42910 helo=reform) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o47tD-0000K2-89; Wed, 22 Jun 2022 17:27:55 -0400 Received: by reform (Postfix, from userid 1000) id E560B2E831BE; Wed, 22 Jun 2022 23:27:53 +0200 (CEST) Date: Wed, 22 Jun 2022 23:27:53 +0200 From: Mark Wielaard To: Siddhesh Poyarekar Cc: libc-alpha@sourceware.org, DJ Delorie , Carlos O'Donell Subject: Re: patchwork upgrade week Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2022 21:30:14 -0000 Hi Siddhesh, On Wed, Jun 22, 2022 at 12:23:56PM +0530, Siddhesh Poyarekar wrote: > On 20/06/2022 15:56, Siddhesh Poyarekar wrote: > This is now done. We're at patchwork 3.0.5, which is the latest available. > Our django installation is at 3.1.14 because 3.1 is the latest patchwork > officially claims to support at the moment. > [...] > I have changed things around a bit in the sourceware patchwork directory and > have documented steps for testing and deploying upgrades to patchwork, > django and anything else in a README file in the home directory. Thanks so much for doing this. And thanks for the extensive README. For others who wish to help with upgrades in the future, please apply for the patchwork group. We were working on adding glibc to builder.sourceware.org (which was how I notice the build breakage I just reported). And you might have seen that for binutils and gdb we are experimenting with git users try branches: https://sourceware.org/pipermail/gdb/2022-June/050173.html Once the new hardware is installed we could also enable that for glibc, but that would only be for people who already have commit access. And you already have the CICD trybot integrated with patchwork so any patch submitter can see try build results. So I was hoping to integrate the buildbot with the patchwork based trybot. But it would be good to have some way to authenticate the patch as genuine before throwing it at the buildbot-worker. I was hoping that could be done by a project admin setting the state of the patch to some "please-try" value. But it looks like a (rogue) user can set the state on their own patch. So relying on the patchwork patch state seems not secure. Or is there a state (maybe a check state?) that we can make sure can only be set by project admins? If not, how else can we authenticate a patch as "OK to let the buildbot do a try build?" Cheers, Mark