On 2024-06-12 06:25:02, Sean Whitton wrote:
> Hello everyone,
>
> This is a draft GR. I'm posting it now for textual review, because of
> the relative shortness of our official discussion periods.
>
> After some time for review, I'll post again seeking seconds.
>
> The first sections are an introductory discussion. For the actual GR
> text, scroll down to the bottom of this e-mail. Thanks.
Hi Sean and dgit folks! :)
Thank you for bringing this up. I think it's important to have this
discussion, at long last, about git and dgit and salsa and ftp and oh
dear...
TL;DR:
1. how does this change my gbp/salsa/dput workflow? can i *just* s/dput/dgit/?
2. does this scale to the archive?
3. what does this mean for salsa/jenkins/bts/etc?
Context
=======
I'm not exactly sure where to start because, I think this proposal is
the tip of a very large iceberg with many components. The other thread
about salsa is one of the chunks lying below the surface, but we could
have the same discussion about the BTS and Jenkins, obviously... This
proposal doesn't *directly* address those, but it definitely goes in a
certain direction and I think a proper GR should more clearly address
that elephant in the room otherwise Further Discussion might ensue, and
we all know how well that goes... ;)
In my case, specifically, as a Debian developer, I wonder how this will
affect me short, medium and long term. For context, I've been using git
for a long time at this point. I've used Alioth and Salsa, I use GitLab
at work and I've also used numerous VCS: RCS, CVS, SVN, hg, darcs, and
what not...
Right now my workflow is basically git-buildpackage + salsa + dput,
relunctantly using pristine-tar sometimes. I have *tried* to use dgit,
but it seemed... rather opinionated about things. I didn't like that it
seemed to have its own ideas as to where I should push my things and how
to lay out the branches on the repository. I've also repeatedly had
trouble grasping exactly how everything works. For example now I thought
"hey, I wonder what dgit does with my packages" and was surprised to not
find any of them on browse.dgit.debian.org... I guess that's because I
haven't used it yet?
1. how does this change my gbp/salsa/dput workflow? can i *just* s/dput/dgit/?
==============================================================================
So, in the short term, I wonder if I should be using this, and if I do,
how much of the dgit workflow would I actually need to adopt. 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...
2. does this scale to the archive?
==================================
In the medium term, I am a little worried about the maintainability of
this. I maintain a GitLab server at work, and we have *just* manage to
retire a secondary, parallel gitolite/gitweb infrastructure, and I'm
quite happy about that. For me, the idea of *re*introducing a *second*
git hosting service in parallel to Salsa seems like a step
backwards. Git repos, while fairly efficient, *do* get pretty big and we
have some pretty massive ones out there (hello Firefox and
LibreOffice!)...
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?
(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.)
3. what does this mean for salsa/jenkins/bts/etc?
=================================================
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),
two (or more?) VCS hosting systems (dgit and GitLab repos)?
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...
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.
a.
--
Il est sage de nous réconcilier avec notre adolescence ; haїr, mépriser,
nier ou simplement oublier l’adolescent que nous fûmes est en soi une
attitude adolescente.
- Daniel Pennac, Comme un roman
