Hi all,
I published a complete rewrite of the earlier draft as:
https://salsa.debian.org/dep-team/deps/-/merge_requests/12
DEP-18: Encourage Continuous Integration and Merge Request
based Collaboration for Debian packages
If you are in favor of having this as a DRAFT in the DEP directory,
please give it a thumbs up.
Summary of previous discussion below, but an even better summary was
written by LWN in https://lwn.net/Articles/986480/
Related to Salsa in general, I heard we have now new and faster
hardware (thanks Salsa Admins!), and related to Salsa CI there is also
an overhauled README
(https://salsa.debian.org/salsa-ci-team/pipeline/-/blob/master/README.md)
and lots of fixes by 7 different authors. I think a lot of people have
also practiced more code reviews and tested the Merge Request feature
on Salsa than before. Overall, I think we are on a good path to
evolving this way of working, and hopefully doing it in a way that it
does not stifle work for maintainers who prefer to continue their
single-maintainer habits, so nobody feels at loss.
On Tue, 27 Aug 2024 at 19:13, Otto Kekäläinen <o...@debian.org> wrote:
>
> 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.
