Re: [RFC] General Resolution to deploy tag2upload
On 2024-06-13 12:38:36, Ian Jackson wrote:
> 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.
I think the dgit documentation is actually pretty good, I don't think
that's the issue here.
>> 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.
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...
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?
> 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.
See that's a different answer than what Sean said, I believe, which is
that you replace `dpkg-buildpackage -S` with git-debpush. :)
> You'll still want to run gbp, etc., as part of your pre-upload
> testing, of course.
Right. But I don't upload the resulting source package, that's thrown
away, basically...
>> 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...
[...]
> 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? :)
>> 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.
Are those two different hosts with their own replicas of the git repos?
Because then that means we have *three* replicas (push.dgit.d.o,
browse.dgit.d.o and salsa.d.o) of those repositories...
[...]
>> 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.)
I do think it's relevant. Right now, there's a huge tension between "the
old ways" of doing things, and some people (at least me) believe we
should be converging towards a smaller set of standard tools that we all
use. I, for example, believe we should all use debhelper and ditch CDBS,
use Git (and Salsa) for keeping history, use git-buildpackage as a
standard workflow. I don't believe it's productive to go around fighting
to standardize this, or at least I don't know how to get there, but
that's my bias.
You, I suspect, have a bias as well. If you don't state it clearly,
people will (and have, already!) speculate as to what your underlying
intentions are. Sean, for example, has clearly stated he likes Salsa and
wants it to stick around, which probably will comfort people who worry
about this.
I think if you, in particular, would speak your mind about this, it
could help alleviate some of those concerns, or at least clarify the
scope of concerns people should have. :p
> 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.
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?
[...]
>> 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.
Yeah, except I suspect a lot of people will not read the entire thread
and it would certainly be useful to have this, if not directly as part
of the GR, at least as an company document of some sort...
At least I know that I don't have time to catchup on all the traffic on
debian-vote and (:surprised-pikachu:) don't always read all those emails
before voting... :)
a.
--
Nothing in life is to be feared, it is only to be understood.
Now is the time to understand more, so that we may fear less.
- Marie Curie
Reply to: