Re: patchwork upgrade week

[Mark Wielaard <mjw@gnu.org>]

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