Antoine Beaupré writes ("Re: [RFC] General Resolution to deploy tag2upload"):
> Well, isn't tag2upload part of dgit? Or at least git-debpush, the binary
> package, seems to be part of the dgit source package here... we're also
> talking frequently about dgit.debian.org as part of this infrastructure,
> so clearly this whole thing is kind of a part of dgit...Rather, dgit is part of the implementation strategy for tag2upload, because dgit is the only program that knows how to canonicalise git trees and turn them into to source packages. And the t2u code lives in src:dgit because src:dgit has lots of useful infrastructure, eg for testing involving git and source packages. > I am not sure saying those things are completely separate here is > helpful, it would be more useful to clarify exactly what component we're > adopting and what patterns we need to change if we want to adopt > this. For example, does this respect DEP-14? Which parts? tag2upload doesn't concern itself with the ref namespace, so those parts of DEP-14 aren't relevant. tag2upload *does* use DEP-14 tag naming, including DEP-14 version mangling. (Indeed as part of our git integraton work, we enhanced DEP-14's mangling to cover a missing edge case.) https://manpages.debian.org/testing/git-debpush/tag2upload.5.en.html#GIT_METADATA > > tag2upload and dgit have many additional safety checks that help avoid > > mistakes. For example, you can be sure that the git tree you are > > about to upload is precisely what ends up in the archive - so you can > > rely on git diff and never need to run debdiff on source packages. > > It is much harder to accidentally undo an NMU. etc. > > This brings another question to mind. Right now, I understand that some > people use dgit for NMUs, on packages they do not own. Does this > workflow still support the old NMU process where i get a debdiff with an > upload someone makes for me, or if someone opts in to this process, for > an NMU, *I*, as a maintainer, now have to figure out dgit? :) Nothing changes for you. An NMUer, whether they use dgit or not, is supposed to send you the diff. (An NMUer who does their work with dgit will probably use git-diff or git-format-patch to generate the diffs they send to the BTS.) With tag2upload you apply the NMU diff to your git tree in whatever way you do so currently. An NMUer can use tag2upload, too. That doesn't interfere with your use of it. > >> 2. does this scale to the archive? ... > > There is one singleton service push.dgit.d.o, ... > > Non-uploading clients use {browse,git}.dgit.d.o. ... > > Are those two different hosts with their own replicas of the git repos? Yes. And if browse.* and git.* become too busy, so need to be scaled up, there will be even more replicas. > Because then that means we have *three* replicas (push.dgit.d.o, > browse.dgit.d.o and salsa.d.o) of those repositories... We have at least five. You forgot archive.debian.org and snapshot.debian.org. (And that's not even counting the maintainer's laptop, temporary clones/copies on salsa and ci.d.n and buildds, and all the copies upstream have.) > > Ultimately, *.dgit.d.o is in some sense a competitor to > > archive.debian.org, but I don't see us abolishing archive.d.o. > > Instead, tag2upload is getting us further towards on dual running, > > where we accept either source packages or git trees, and publish both. > > hmmm... maybe I'm missing something, but archive.d.o also has binary > packages, dgit.d.o doesn't do that, does it? Or are you only refering to > the source packages part? Yes, you're right, only the source packages part. 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.
