Re: [RFC] General Resolution to deploy tag2upload
Antoine Beaupré writes ("Re: [RFC] General Resolution to deploy tag2upload"):
> Right now my workflow is basically git-buildpackage + salsa + dput,
> relunctantly using pristine-tar sometimes.
> I have *tried* to use dgit, but [...]
I think maybe I should make a blog post explaining what dgit is, and
isn't. But that's probably rather out-of-scope for this thread.
> 1. how does this change my gbp/salsa/dput workflow?
> can i *just* s/dput/dgit/?
By "this" I'm going to take you to mean "tag2upload".
With tag2upload you don't run dgit.
You replace gbp/salsa/dput with git-debpush. git-debpush will push to
your branch salsa for you, as well as making and pushing the git tag.
The tag2upload service will take care of the rest.
You'll still want to run gbp, etc., as part of your pre-upload
testing, of course.
> Can I just keep doing gbp + salsa and switch the "dput" bit to
> "dgit" or "tag2upload" without changing anything else? That would be
> kind of neat, but I'm not sure *why* I would do that in the first
> place...
There are two good reasons why you might want to adopt tag2upload,
(and they mostly apply to dgit push).
Firstly, tag2upload is much simpler, more convenient and faster.
(dgit is also simpler to use and more convenient, but not quite so
simple as tag2upload, and it isn't faster than old-school uploads.)
Secondly, tag2upload is more reliable, more traceable, and provides a
better result for users. (These advantages apply to dgit too.)
NB "reliable" here often means "more likely to stop and report a
problem, than blindly carry on and perhaps do a wrong thing".
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.
> 2. does this scale to the archive?
> ==================================
...
> So what's the plan for dealing with the sheer size of the Debian
> archive, assuming that eventually everything might reasonably be
> expected to be *both* on dgit and salsa, if I understand the proposal
> correctly?
It's true that this is a lot of data. It's going to be comparable in
size to the archive. Scalability is a reasonable concern.
There is one singleton service push.dgit.d.o, which is used only by
uploaders (and the tag2upload robot). So it shouldn't become
overloaded.
Non-uploading clients use {browse,git}.dgit.d.o. Currently that is a
single host, which is also shared with some other services. But it is
a read-only mirror and we could scale up to multiple mirrors.
> (Well, technically, the proposal says "this is opt-in, entirely
> optional", but Ian at least has explicitly stated he expects people to
> enthusiastically start to use dgit massively in the future, so even if
> that's not actually part of the proposal, we should take that scenario
> into account.)
YM enthusiastically start to use tag2upload. But, yes.
> 3. what does this mean for salsa/jenkins/bts/etc?
Nothing.
> In the long term, what do you actually think we should do about the
> duplication of tools out there? We are wasting a lot of energy here
> maintaining two CI systems (Jenkins and GitLab CI), two bug trackers
> (BTS and GitLab issues), two wiki systems (MoinMoin and GitLab Wikis),
I don't think I have an opinion about that. (Or at least, maybe I do,
but it's not relevant.)
tag2upload is not a competitor to any of the things you list.
In the long term, tag2upload depends on there being one or more things
that are a enough like git forges that they can call webhooks and
serve up git tags. Right now that's Salsa. If Debian wants to
replace gitlab with some other forge that's not something that
tag2upload has much of an opinion about.
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.
> two (or more?) VCS hosting systems (dgit and GitLab repos)?
dgit-repos is complementary to gitlab. (The relationship to salsa has
been discussed extensively elsewhere in this megathread.)
> I understand the proposal doesn't directly say "oh yeah, we're actually
> thinking we should ditch salsa and replace it with all those nice little
> small components", but it is certainly taking a stand that Salsa is not
> good enough to provide the level of security that is required to upload
> packages in Debian, and saying that is saying a lot because I suspect we
> are *actually* trusting Salsa and GitLab with our code much more than we
> would like to admit...
To be completely clear: tag2upload is not a replacement for Salsa, and
it cannot be such a replacement. In the planned deployment it
*depends on* Salsa.
> Anyways, I hope I'm not throwing a brick here, I do really have those
> questions and concerns and I am hoping a GR would pre-emptively answer
> them so we have a better idea of what we're actually voting on here,
> because I think the proposal, as it stands now, hides a lot of the
> unresolved issues and problems we have.
Past experience with GRs suggests very strongly that GR proposals
should be short. So I think the background has to be outside the
formal GR - in places like this discussion thread.
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: