On Mon, Feb 28, 2022 at 9:48 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. > > I have just realized something, I don't think we're planning on restricting the > access to the old lookaside upload script (the idea you're talking about in the > first paragraph), so if we are not, we are not breaking backward compatibility, > just introducing/offering another way to do things: > - either you keep your current workflow and upload as you do today with the > current lookaside upload endpoint > - or you adjust your workflow and upload to the lookaside cache using the new > endpoint. > > Both approach would work equally well. > > And this is where it does ties the git server and git structure to the > lookaside, if a SIG keeps using git.centos.org, they will have to keep using the > current branch structure and thus changing their workflow to use the new > lookaside cache endpoint does not bring them anything, they can just keep doing > their work the way they have always been. > If a SIG chooses at some point to start using gitlab, they will have to adjust > their workflow (if only to change the hostname of the git server) and they will > have the choice: > - either keep using the branch structure that git.centos.org imposes (but that > time it won't be imposed, it'll be by choice) and then they pick which > lookaside upload endpoint they use > - or they choose a different git branch structure (so another change in their > workflow) and there, they won't have the choice and will have to use the new > lookaside upload endpoint. > > So it seems simpler to me to keep with the original idea of having two lookaside > upload endpoint, the current one keeping the current structure and a new one > using the structure used by CentOS-Stream and Fedora. > So what you're saying is that I could just use the new endpoint? If that's the case, then I can *still* use this with git.centos.org if I want. I would just get the flexibility to use the flat layout and I can cherry-pick commits from Fedora or CentOS Stream as needed. -- 真実はいつも一つ！/ Always, there's only one truth!