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