Le mer. 21 août 2024 à 03:36, Otto Kekäläinen <o...@debian.org> a écrit :
> Hi! > > In short: > I would very much like to see all top-150 packages run Salsa CI at > least once before being uploaded to unstable. What people think is a > reasonable way to proceed to reach this goal? > > > Background: > We have had several cases recently where an upload to Debian unstable > causes widespread failure in unstable, and it could have been easily > prevented if Salsa CI pipeline had run for the package and revealed > the problem before upload to archive for everyone to suffer. > > This message was prompted by the fact that right now we have a massive > large of Python packages affected by the "No module named 'packaging'" > bug [1] which would have been caught by Salsa CI running the > autopkgtest job before upload [2]. I don't want to blame maintainers > for missing on some details while doing new releases - it happens. But > systematically not using available and easy testing facilities does > annoy me. > > We can't have Salsa CI for all of Debian overnight, but at least > widespread issues could be mitigated significantly by having Salsa CI > at least on the top-150 or top-500 packages. > > We do not have stats on how many packages use Salsa CI, but we have > stats on how many are not even hosted on Salsa: > > ``` > curl -LO https://trends.debian.net/vcs-hosting_unstable-packages.csv > curl -LO https://popcon.debian.org/sourcemax/by_inst > for x in $(tail -n +13 by_inst | head -n 150 | cut -c 7-25) > do > grep -E "^$x," vcs-hosting_unstable-packages.csv > done | grep -v salsa > > dpkg,1.22.10,other > coreutils,9.4-3.1,no vcs > acl,2.3.2-2,other > zlib,1:1.3.dfsg+really1.3.1-1,no vcs > attr,1:2.5.2-1,other > hostname,3.23+nmu2,no vcs > readline,8.2-4,no vcs > e2fsprogs,1.47.1-1,other > base-files,13.3,no vcs > bash,5.2.21-2.1,not git > expat,2.6.2-1,no vcs > gettext,0.22.5-2,no vcs > diffutils,1:3.10-1,no vcs > libbsd,0.12.2-1,other > sqlite3,3.46.0-1,no vcs > dmidecode,3.6-1,other > pciutils,1:3.13.0-1,other > libxdmcp,1:1.1.2-3,git on alioth > wget,1.24.5-2,no vcs > file,1:5.45-3,other > laptop-detect,0.16,other > fuse,2.9.9-8.1,no vcs > lsof,4.95.0-1.1,no vcs > scowl,2020.12.07-2,other > emacsen-common,3.0.5,no vcs > libusb-1.0,2:1.0.27-1,no vcs > setuptools,70.3.0-2,no vcs > traceroute,1:2.1.5-1,no vcs > liblockfile,1.17-1,github > ``` > > If you are a maintainer of a top-150 package and want help in getting > it on Salsa and have Salsa CI activated, just email debian-salsa-ci@, > and we will guide you through how to best run `gbp import-dscs > --debian-branch=debian/latest --upstream-branch=upstream/latest > --pristine-tar`, what to put in a README.source how to activate Salsa > CI with potential customizations you feel are make sense. We have > already done this to many projects, but as surprisingly many > maintainers prefer not to receive contributions, we encourage those > who want to have help to reach out themselves. > > When I proposed DEP18[1] my main motivation was to get more packages > on git and on salsa.debian.org so that it is easier to collaborate on > the next upload with the maintainer and all interested contributors > before the upload is done. Collaborating on packages by NMUs is just > not a modern and efficient way to collaborate. > > On top of this, I also wished that packages would use Salsa CI, at > least once before the upload. This helps the maintainer get assurance > of the package health before upload. Running Salsa CI on Merge > Requests automatically helps contributors get immediate feedback, and > it also gives the maintainer assurance that contributions don't cause > easily testable regressions. > > Many people raised concerns on DEP18, and some of them are valid, and > I will continue to ponder about it and how to restructure the proposal > to foster collaboration without alienating any of our current > maintainers who have a well optimized existing workflow. > > However, pushing for wider Salsa CI adoption I think makes sense as a > goal by itself, and I would be keen to hear what people think is a > reasonable way to proceed with that? > > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079175, > https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/376 > [2] > https://salsa.debian.org/python-team/packages/setuptools/-/jobs/6156348 > [3] https://salsa.debian.org/dep-team/deps/-/merge_requests/8 A bunch of packages I know (nodejs, receptor to name a few) have salsa CI failures, but no sbuild failures. It would be perfect if the build process was exactly the same. Jérémy
