Hi! > I'd like to rephrase your quest. What you really want is unstable to be > less unstable. Whilst a number of people disagree with that notion, I
I don't think anybody disagrees that breaking a core packages and stopping (nearly) all other DDs from doing development for a day or two is acceptable. I do agree that there are some developers who view unstable as a CI system by itself, and we occasionally see certain DDs do multiple uploads in a few days for the same package after they read the QA system results. This is better than nothing, and maybe OK for small/unimportant packages. For important packages I think it would be vital to have enough CI should run before upload unstable, and use unstable only to detect stuff that is hard to gate keep with automatic testing (as you wrote in slightly different words). > One complaint I've seen about this workflow and one that I agree with is > the waiting time. Checking salsa-ci before uploading incurs an extra > context switch. What we'd really like to do is click the equivalent to The CI waiting time is always less than human review waiting time. For example in https://salsa.debian.org/debian/entr/-/merge_requests/10 the CI took 10 minutes, but it will take several days for a reviewer to respond on the MR itself. Also, I think a 10-minute break is a good thing for the author themselves. The maintainer should get some fresh air and do the final review of their changes after a small break to ensure nothing was done too hastily. > "Auto-merge" (if the pipeline passes). As I write this, Sean or Ian will > likely come along and say tag2upload. Working in this direction and > enabling a "upload if ci passes" would bring the salsa-ci experience to > another level. This would be super cool, in particular if it was extensible to get triggered automatically when a new upload has had a minimum number of approvers in the MR, and it would got merged and tagged and uploaded automatically. > Let me suggest that there are more ways to do this. Freexian is putting > a ton of effort into https://debusine.debian.net. It can do much of the > same tasks as salsa-ci already (with less flexibility). Extending it to > act as an upload-proxy that forwards your upload to the archive if > builds pass could be another option of improving unstable quality. In > earlier times, debomatic.debian.net was used as a pre-upload QA tool if > I remember correctly. I used to use debomatic.debian.net, and I have been reading about Debusine and the funding it gets from the Sovereign Fund. I tried to use Debusine back in March, but the client requires Python 3.11+ which my system does not have. I will need to make a new attempt soon. Thus, I don't have any good opinion about it yet. However, as you probably guess, I have a strong preference for workflows that integrate version control and code reviews and CI. This is what Salsa does (and GitLab, GitHub and alike). > Then the top-150 packages tend to be packages with unusual aspects. For > instance, the git repositories for gcc-VER, glibc and linux all lack > upstream sources. For linux, there is a pipeline, but in order to > complete in a timely manner, it enables the pkg.linux.quick build > profile and the pipeline is elaborate with a complex extract-source > stage. It's not a matter of just enabling the pipeline for our core > packages but spending a lot of time fiddling with the settings until it I have been reading the Kernel team Salsa CI before, and I am impressed how the pipeline has been customized, and glad to see it was green for the latest upload: https://salsa.debian.org/kernel-team/linux/-/pipelines/720187 I suspect you are right that some of the top-150 packages are special case that can't use Salsa CI easily, but for example the setuptools that had #1079175 yesterday would have been able to run Salsa CI without anything custom (just a debian/gbp.conf file to define how it needs to be built from git, see https://salsa.debian.org/python-team/packages/setuptools/-/commits/debian/latest/). > works. I guess that sending a working pipeline configuration for these > could improve the situation. Would it also make sense to source I have done that - details visible in my MR history at https://salsa.debian.org/dashboard/merge_requests?scope=all&state=all&author_username=otto&search=%22enable+salsa%22 - and will continue to. For example, after #1071245 happened, I sent to GnuPG an MR that enabled Salsa CI and included fixes to make it green. Inspired by #1021336 I just sent one to PAM this week. Some maintainers happily accept it, but surprisingly many reject, and I have no backbone from any DEP or GR or policy to ask them to seriously consider using Salsa CI. Some even say that they don't want to look at MRs at all, no matter how many fixes might be pending there on a silver plate. It is a lot of work to do these contributions and frustrating when people reject them without any real reason, just some expression of personal preference. Having some discussions on debian-devel@ might make people change their personal preference in favour of a collective preference. > dedicated gitlab runners for heavy core packages to further reduce the > feedback time and the impact of enabling CI there? I am aware of many who happily would donate hardware for runners. I guess this is mostly a question of documenting how to add runners so people doing it can avoid reinventing the wheel or wasting unnecessary time on failures that stem purely from inconsistent runner configurations. Dedicated runners could also be faster as they could be using local cache unlike random runners that can't properly benefit from caching. > Given this I want to resonate what others already said. This seems more > like something to put effort into and make it work practically than > worth discussing. Doing a survey mail to the relevant maintainers for > figuring out where to best direct that effort also seems sensible to me. Thanks! I will publish a draft for comments and later proceed to send targeted emails.
