On Mon, Feb 21, 2022 at 11:16 AM Pierre-Yves Chibon <pingou at pingoured.fr> wrote: > > On Mon, Feb 21, 2022 at 10:58:58AM -0500, Neal Gompa wrote: > > On Mon, Feb 21, 2022 at 10:51 AM Pierre-Yves Chibon <pingou at pingoured.fr> wrote: > > The git server and git structure is orthogonal to the lookaside > > problem. Fundamentally, the issue was that the same upload endpoint is > > used for both Red Hat compliance and SIG work. We already have > > authentication/authorization on branches at the Pagure level, so we > > just lacked a way to handle this for the lookaside upload. By > > splitting the endpoint, it should be possible to solve that since you > > can deny access to the Red Hat endpoint to everyone. > > > > However, I'd make a small suggestion: instead of changing the endpoint > > URL for SIGs, change the endpoint URL for Red Hat. RCM uses that > > endpoint through automation (I assume), so changing the endpoint for > > the one service is considerably simpler than dealing with everyone's > > own scripts to adjust for SIGs. > > That is an interesting point, I'll ask around to know how feasible it would be. > > > As an example, I've written automation to deal with Hyperscale work > > because doing it by hand is a lot of grunt work. While I can probably > > tweak my stuff easily enough, I don't know if *everyone* can. > > Your automation doesn't use the `lookaside_upload` script from > centos-git-commoin then? > I have a vendored copy of stuff from centos-git-common. But other people may have taken different approaches. > > And again, the lookaside thing is completely orthogonal to the git > > structure. I should be able to use it just fine from git.centos.org in > > the current branched package structure. > > I agree, though dropping the branch structure that git.centos.org imposes > exacerbates this. > I don't know that we want to change the current structure used for all SIGs (vs > making it opt-in), but it is an interesting thought. > There are some advantages to the existing per-branch structure. I've used to easily sync and merge Hyperscale modifications onto c8s packages for Hyperscale 8 package builds. That benefit will be gone with c9s, but it was handy with c8s. -- 真実はいつも一つ！/ Always, there's only one truth!