VCS (Was: Questions for all candidates)
Dear Jonathan,
I'm continuing with your next set of questions for the topic VCS.
You can find my answer about the Community team question here[1].
> 2. VCS
>
> Salsa has been stable for a number of years now, and git is clearly a good
> choice of default VCS (even though not perfect or preferred for all).
>
> How do you feel about VCS requirements in Debian? Should it be required that
> Debian packages are maintained in Salsa?
It should be required that Debian packages are maintained in VCS (which
these days is synonymous with Git) and hosted on a unified development
platform. Currently, that platform is Salsa (formerly we had Alioth with
the restrictions that made us move away), and if someone develops an
alternative that addresses the concerns raised about our GitLab
instance, I'd be open to considering it. But for now, our goal should be
to host all packages on Salsa since this has proven to be fine in
production.
If you ask whether this can realistically be accomplished within the
next DPL term, my answer is a clear no. I am well aware of the
discussions and the objections raised against this plan. However, I
believe the benefits far outweigh the drawbacks. These include easier
collaboration, especially for newcomers, better tooling for large-scale
package changes, greater consistency across Debian packaging, and CI
testing.
For now, I will focus on migrating packages that remain outside Salsa
_for_ _no_ _good_ _reason_-for instance, cases where the maintainer is
inactive, and nobody truly cares. Last year I used some UDD query[2]
udd=> SELECT DISTINCT count(*) FROM sources WHERE release = 'sid' and vcs_url not like '%salsa%' ;
2368
At that time, I stated that I would like to reduce the latter number
below 2000. As of today, it stands at 1653. However, it was later
discussed [3] that the old query was incorrect. I have proposed a new
query [4] that should accurately identify all affected packages:
udd=> SELECT COUNT(DISTINCT source) FROM sources WHERE release = 'sid' AND
(vcs_url IS NULL OR vcs_url like '%alioth.debian.org%' OR vcs_url like '%git.debian.org%' OR vcs_url like '%svn.debian.org%' OR vcs_url like '%anonscm.debian.org%') ;
count
-------
2509
At the time of writing this query to the list 2025-01-08 this number
was 2930. So something happened in the last 2.5 months and I intend
to continue with this.
I want to repeat what I stated very clearly last year: If you do not
believe that all Debian packages should be maintained on a common
Git-based platform, then you should not vote for me. I will not achieve
this transition within a single year, but I am committed to paving the
way toward it.
> How do you feel about dgit
As long as dgit is seen as just another interface (like gbp), I'm
perfectly fine with it. Ultimately, the choice depends on your workflow.
While I personally use gbp, I've seen dgit in action with Salsa, and if
it fits the needs of others, that's great.
> and tag2upload?
>From my perspective, tag2upload offers a modern alternative to the
over-30-year-old method we currently use to upload packages. While my
current workflow doesn't present any issues that tag2upload might
address-and thus I haven't felt a need to use it myself-I see it as a
positive step towards modernization. I consider tag2upload part of
Debian's ongoing efforts to enhance our processes, and I'm interested to
see where it takes us. Finally, it may serve as a stepping stone on the
path I intend to pave towards unified Git-based workflows across Debian.
> Do you have any ideas about VCS use in Debian that you would promote as DPL?
I basically answered this question above, but to reiterate: My strategy
as DPL is to join forces with other DDs to move packages to Salsa that
have been somehow "forgotten." Many packages that do not have their Vcs
fields set to Salsa are even hosted there, but they have not been
uploaded by the team maintaining them with updated Vcs fields. I believe
this is an easily solvable problem within one additional year. During
the Bug of the Day effort, I encountered many cases where not being
maintained on Salsa was a minor issue compared to other QA problems. In
the responses I received from the maintainers of these packages, the
vast majority were positive.
> A while back someone told me that they want to NMU one of my packages. It
> was maintained in /debian on salsa, so I reminded them that this is
> basically collab-maint these days and they did the right thing and just did
> a team upload instead. Julian mentioned common package maintenance in how
> it's done in Ubuntu. What do you think about the /debian team and would you
> want to promote the use of that as DPL?
I think the /debian team is a great idea, and I actively use it. As DPL,
I fully promote its use. Thank you for pointing this out.
Kind regards
Andreas.
[1] https://lists.debian.org/debian-vote/2025/03/msg00047.html
[2] https://lists.debian.org/debian-vote/2024/03/msg00057.html
[3] https://lists.debian.org/debian-devel/2025/01/msg00078.html
[4] https://lists.debian.org/debian-devel/2025/01/msg00128.html
--
https://fam-tille.de
Reply to: