Jonathan Carter writes ("Re: [RFC] General Resolution to deploy tag2upload"):
> On 2024/06/12 10:21, Luca Boccassi wrote:
> > 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.
>
> I found the overview of tag2upload from Ian at MDC Campbridge quite
> useful (and the workflow diagrams that he presented). From my
> understanding (and I may still have the wrong end of a stick here), the
> additional git store used for tag2upload becomes a replacement for
> source packages that happens to use git. So from my understanding, it's
> more a competitor to source packages rather than to salsa.
Yes. Russ's comparisons to archive.d.o and snapshot.d.o are helpful.
(Because git inherently has history, the dgit-repos server can
perform both functions at once.)
Scott Kitterman writes ("Re: [RFC] General Resolution to deploy tag2upload"):
> I think it is more accurate to say that they are mirrors. They both contain
> details of current and historical packages. The difference is that snapshot
> is downstream of the archive, while these putative the tag2upload
> repositories are upstream.
>
> It's it being upstream of the primary archive that makes it far more security
> sensitive.
The dgit-repos server (*.dgit.d.o) is not upstream of
archive.debian.org.
The tag2upload conversion server is upstream of both, and is indeed
very security sensitive.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
