DEP-18 discussion summary (Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages)
Hi!
While I intend to continue on iterating DEP-18, here is a summary to
those who did not wade through the 140+ messages on the topic.
Unfortunately, the summary itself is also a bit long :)
********************************************************************************
Summary of mailing list discussion in
https://lists.debian.org/debian-devel/2024/07/msg00429.html
## Overall Sentiment
There was a broad consensus that Debian workflows are too fractured
and would benefit from more standardization and unification. However,
there were differing opinions on the right approach to achieve this.
Soren Stoutner expressed this sentiment clearly:
> 1. Debian workflows are too fractured. The project would be better if we asked people to standardize around a single (or a small number) of workflows. To do so, the workflow would need to be flexible enough to handle the wide range of technical needs of all the packages and upstream configurations.
> 2. Standardizing around a single (or small number of) workflows wil make some people unhappy. But that is an acceptable price to pay because of the general benefit to the project as long as the correct solution is adopted. Unity is more important than minority opinions on this particular issue.
Similarly, Andrey Rakhmatullin argued that while some may resign, "the
'1000 DDs status quo' problem also means that more people leave than
join _anyway_. Not the unity per se, but having significantly lower
barriers to start contributing" is important.
## Git and Gitlab Usage
Multiple participants noted that most other Linux distributions use
Git as the primary version control system, often with GitLab or GitHub
for collaboration. Debian's multi-branch approach with pristine-tar
was seen as somewhat unique.
There were differing views on whether Debian should move closer to the
more common Git-based workflows used elsewhere, or maintain its own
custom approach, which of git-buildpackage and dgit are the most
common ones (both with multiple ways to use them).
## Mandatory vs Optional Policies
Some participants, like Salvo Tomaselli, felt DEP-18 was too
prescriptive in mandating specific tools and workflows, and that a
more flexible, optional approach would be better:
> Keep in mind that unhappy people quit. I don't think that unity is so important that we're willing to sacrifice project members.
Others, including Soren Stoutner, argued that standardization was
important, even if it made some people initially unhappy, as long as
the right solution was adopted: "Unity is more important than minority
opinions on this particular issue."
## Maintainer Workflows
There were concerns that requiring specific Git and Gitlab practices
could create burdens for existing maintainers, especially
single-person maintainers. Sean Whitton described his own preferences
as a maintainer:
> I am happy to use salsa for git hosting and access management. I love that I can easily grant push access to my non-DD team members. But, I turn off salsa MRs for the repos of all packages I regularly upload. I would hope that this DEP can be written such as to account for these sorts of choices. Fabio Fantoni suggested allowing maintainers to specify their preferred collaboration methods in a machine-readable way, for example through a "Collaboration-Policy" field in debian/control.
## Performance and Reliability
Multiple participants, including Salvo Tomaselli, Johannes Schauer
Marin Rodrigues, Andrea Pappacoda, and Gioele Barabucci, complained
about Salsa/GitLab being slow or unreliable at times, which deterred
contribution. Improvements to performance and uptime were seen as
important. In response, Otto Kekäläinen noted that the Salsa admins
had posted about upcoming hardware upgrades and other improvements to
address these issues at
https://salsa.debian.org/salsa/support/-/issues.
## Machine-Readable Metadata
Fabio Fantoni and Niels Thykier proposed including more
machine-readable metadata about packaging workflows (e.g. in
debian/control) to help automate contributor onboarding. Niels Thykier
outlined some specific examples of information that could be captured:
> Does this package use `gbp dch` (or some other mechanisms) to generate the changelog OR should I include a changelog entry with my patch. Does this package use some form of automatic formatting that I should apply when I do my changes (if `wrap-and-sort`, then which options)? Does the maintainer prefer MR via salsa or BTS with patches for when I want to submit my changes for review.
## Overall
There seemed to be general agreement that improving collaboration was
important, but the right approach was still being debated.
## Mailing list participants
- Jonas Smedegaard
- Salvo Tomaselli
- Luca Boccassi
- Charles Plessy
- Marco d'Itri
- Sean Whitton
- Marc Haber
- Jeremy Stanley
- Shengjing Zhu
- Noah Meyerhans
- PICCA Frederic-Emmanuel
- Fabio Fantoni
- Kentaro Hayashi
- Tobias Frost
- Gioele Barabucci
- Blair Noctis
- Andrea Pappacoda
- Soren Stoutner
- Andrey Rakhmatullin
- Paul Gevers
- Niels Thykier
- Simon Richter
- Chris Hofstaedtler
- Johannes Schauer Marin Rodrigues
********************************************************************************
Summary of the 70+ comments in this
https://salsa.debian.org/dep-team/deps/-/merge_requests/8
There were some differing viewpoints on this many parts of the
proposal, but also lots of support.
**Opposition to using Salsa/GitLab:**
* mirabilos strongly opposed using Salsa, stating "Salsa is inherently
a nōn-free tool...I strongly believe forcing people on GitLab is an
SC/DFSG violation."
* Joachim Zobel had the opposite view of caring purely about usability
and asking "Why is maintaining a Debian package on GitHub against
DEP-18?"
* Salsa could be viewed as a middle ground between the above options.
* Helmut Grohne raised concerns about lack of consensus, saying "Given
that there are at least two competing hosting options with similar
adoption, I question the unilateral choice of one of them."
**Concerns around merge request process:**
* Louis-Philippe Véronneau pointed out "MRs really don't work well
with some of the current git workflows...reviewing such contributions
is a ton of work."
* Simon Richter argued "The entire DEP except for this paragraph very
carefully avoids making any technical recommendation...If this DEP
should be useful at all, it needs to make a technical contribution."
* A future version needs to list examples of packages that have
reviews before upload to paint a picture how it works in practice (and
that it is doable)
**Support for using GitLab/Salsa:**
* Guido Günther said "Fragmentation...is an issue so recommending
salsa makes a lot of sense from Debian's PoV."
* Andreas Tille stated "We simply loose people who are frustrated that
its impossible to do Debian wide changes easily...Its simply not
sufficient for say running Janitor like tools on random Vcs locations
outside Salsa."
* Blair Noctis argued "At this stage of the free software movement
we...need more hands to compete with non-free things...Machines and
tools should adapt to people, not the other way around."
**Other viewpoints:**
* Chris Hofstaedtler asked "Please provide a clear definition of what
this DEP wants to achieve. Right now it lives off a headline of "true
open collaboration" without defining that."
* Bastian Venthur noted "DEP-14 is not accepted yet, but in the
candidate state since 2020."
* The discussion surfaced well what are the shared pain points in the
packaging workflow beyond just collaboration struggles. Work should
also continue on DEP-14, git-buildpackage, Salsa CI and other tools to
decrease the general friction, and in many places simple documentation
updates/overhaul is due to avoid unnecessary fragmentation in
workflows that isn't intentional so that we later can more clearly
focus on discussion the pros and cons of the intentionally different
workflows.
Reply to: