Re: [RFC] General Resolution to deploy tag2upload [and 1 more messages]
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 <ijackson@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.
Reply to: