Hi Otto, Quoting Otto Kekäläinen (2024-07-28 00:38:40) > I have drafted a new DEP at > https://salsa.debian.org/dep-team/deps/-/merge_requests/8 titled "DEP-18: > Enable true open collaboration on all Debian packages". > > Direct link to raw text: > https://salsa.debian.org/dep-team/deps/-/raw/798bfa5a1e1609afd4e48ee20aff80a82bcd4a2f/web/deps/dep18.mdwn > > This would have been a great topic to discuss in person at DebConf, but > unfortunately I can't attend this year, so I'll just kick this off on the > mailing list.
thank you for working on this. > This is continuation to the 'single maintainership' discussions earlier this > year. I also think that more unified and open collaboration processes could > help decrease maintainer burnout, lower barrier for existing and new > maintainers to help with multiple packages, and overall perhaps also improve > quality of uploads by having more attention on the source code prior to > upload. A slightly related topic: what is everybody's opinion on maybe starting with some of the basic items of DEP-18, lets say items 1-3, and prescribe them to only a very small set of packages in Debian. And which set of packages in Debian should *especially* have easy open collaboration enabled if not the set of source packages producing our Essential:yes packages? So why not start with the source packages in the Essential:yes set, have them adhere to better collaboration standards like packaging in git on salsa and with salsa CI enabled? I am aware that this might just be a pipe dream because at least in my personal experience I observed very strong package ownership especially for packages in the essential set. But I think it is the set of Essential:yes packages which should set an example of how collaborative maintenance in Debian is supposed to work because in contrast to other packages, the Essential:yes set is relevant to literally all of us. Bugs in those packages affect us all, so we all should have an easier time to collaborate on them, right? Bugs like #1021336 had to be closed *twice* because of issues that would've been caught by the salsa CI pipeline. It doesn't help that a MR enabling salsa CI for that package is waiting to be acted upon by its maintainers since October 2022. It is literally essential (pun intended) to all our work that packages in the essential set do not accidentally break. The chance of this happening can be greatly reduced by requiring a passing salsa ci pipeline with successful autopkgtest, piuparts and lintian. What am I missing? To those who refuse to work with salsa CI because it is slow (yes it is, I know because my processor is probably 10 times slower than yours) I can warmly recommend the glab utility from the package of the same name. My Debian workflow has now these two commands added after I "git push" my work: - glab ci status --live - glab ci trace The former will let me follow the pipeline for my last commit as it is running without having to open it in my browser (which is painfully slow). The latter will let me look at the stdout and stderr of the job of my choice (usually the failing one) without some javascript deciding that it will remove the whole text from my screen with the error message "An error occurred while fetching the job." > If you think this proposal makes sense, please press the thumbs up button. > > If you have comments, please share them here or on the draft itself. I think I like all items you brought up except for item 5. At least in the part of Debian where I am active, I find it very hard to find anybody reviewing my stuff, probably because everybody else is already overworked themselves. So I think it's nice but I do not see us having very much volunteer time to really have this work in practice. But maybe there are teams for which this really works well? In any case, nothing I'd like you to remove but maybe it's too much of a dream? :) Thanks! cheers, josch
signature.asc
Description: signature
