[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [RFC] General Resolution to deploy tag2upload



On Wed, 12 Jun 2024 at 02:31, Russ Allbery <rra@debian.org> wrote:
>
> Luca Boccassi <bluca@debian.org> writes:
>
> > And on the implementation details, I really do not like the idea of
> > having a competing git forge with Salsa. This dgit server seems to just
> > be a ye olde git-web interface.
>
> 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/

> > If this goes forward, in my opinion it should exclusively use Salsa as
> > the git server, to avoid duplicating infrastructure.
>
> I think you want the Git archive to be entirely separate from Salsa so
> that it's a reliable source of tracing information.  You don't want to
> support force pushes, for example; the whole point is that it should be
> append-only, which would be a controversial choice for Salsa but which is
> fine for the archives of the uploaded packages.  I would also want a much
> smaller attack surface for that type of record than than GitLab.  GitLab
> is designed as a place to do interactive work, not to keep a reliable
> permanent record.

The git repositories, sure. The git forge? I don't see why. You can
have these repositories in a separate namespace, which sets strong
branch and tag protection rules to achieve what you describe. As far
as I am aware, this is possible to do in Salsa already, it doesn't
have to be a per-forge rule, it can be per-namespace, I think this is
possible to achieve in Gitlab. I have not used tag protection rules
(on gitlab, I used them on github though), but I do regularly use
branch protection rules on my Salsa repositories.

To be clear, I am exclusively talking about the git forge, as in
salsa.debian.org, not the git repositories as they might exist on
Salsa under the debian/ namespace or any other namespace.

Having a separate namespace with strong ACLs seems exactly what you
want, even if it duplicates the individual repositories (the backend
git store deduplicates it anyway, so in practice it should be quite
cheap). Having an entire separate git forge that competes with Salsa
seems orthogonal to this, and counterproductive for the project.

> That Git archive is not parallel to or competitive with Salsa and doesn't
> provide most of the functionality that Salsa does.  It has a different
> purpose.

I disagree strongly. As we have seen in the recent Salsa thread on
d-private, there are a few but very strongly opinionated people who
are vehemently against Salsa and would like to see it gone. Having a
parallel and competing git forge I fear would give them very strong
ammunition to do so: "if the real uploads and the real repositories
are on a separate and independent git forge, why have Salsa at all?
Get rid of it and use the other forge exclusively."


Reply to: