On Wed, 12 Jun 2024 at 12:10, Ian Jackson <[email protected]> wrote: > > Luca Boccassi writes ("Re: [RFC] General Resolution to deploy tag2upload"): > > On Wed, 12 Jun 2024 at 02:31, Russ Allbery <[email protected]> wrote: > > > Does it support gitweb? I thought it only supported regular Git > > > operations, but I could be mistaken. > > > > I might be wrong, but this is what this looks like to me (it was > > linked to me on IRC yesterday, wasn't aware of it before): > > > > https://browse.dgit.debian.org/ > > Thanks for taking an interest. > > That is indeed a cgit view of the dgit git server. > > > The git repositories, sure. The git forge? > > I'm not sure what you mean by "forge". I think "forge" means > "something like gitlab / sourcehut / github / ...". Ie, a system > which doesn't just do git repository hosting, but also has (some or > all of) a linked issue tracker, merge request review systme, > discussion tooling, CI, etc. > > The t2u/dgit git server doesn't have any of those things. It's purely > a git server, with some bespoke access control. So I don't think it's > a "forge". > > It *does* present the contents of its repositories via a web interface > for use by a web browser, but that view is completely read-only. > (Indeed in the current setup in Debian it's served from a mirror.)
This is largely in the eye of the beholder as there's no strict definition that I am aware of, so one could or could not include these, but I do note that what you describe above is not really that different from Alioth - that also didn't have merge requests or CIs, and we didn't really use the rudimentary ticket system (IIRC it did have one? Might be wrong). If Alioth was a forge, and I think it was, then this alternative system also sounds like a forge to me. One might have a different definition that results in different subsets being included, but to me a forge is fundamentally a remote git server hosting multiple repositories, where multiple people push to. > Whatever the definition of "forge" the key point you are making is > that you see it as competing with Salsa. But, I don't think it does > compete with Salsa. It doesn't offer any of the useful features that > Salsa has. > > (In another sense, the Debian archive + ci.debian.net + the BTS + > britney etc. etc., *is* competing with Salsa. In this view of things, > browse.dgit.d.o is a view of part of the archive. But I don't think > that's where you're coming from.) Well, yes that is where I am coming from, as that's one of the arguments being made by those opposed to Salsa. My understanding of that position is the fact that it doesn't offer features is a _plus_, not a minus. > Salsa is not really suitable for use as the t2u/dgit repos git server, > for the reasons others have explained in this thread. Very early in > dgit's history, the dgit repos were hosted on Alioth, but we replaced > that with a dedicated server for many reasons, some of which are > security-related and discussed in Russ's review. As far as I can tell, from what was shared in these documents, the security feature needed is an append-only repository, with safeguards that an individual developer cannot bypass. As far as I can tell, the same setup can be achieved with repository ACLs, and it would have the same vulnerability: an admin with full access to the server can bypass such measures, in either case. Is there something else I am missing?
