Hi, Quoting Hideki Yamane (2022-10-07 03:39:39) > On Thu, 6 Oct 2022 17:45:06 +0200 Michael Biebl <bi...@debian.org> wrote: > > If you are using salsa, you can utilize all the features gitlab > > provides. E.g. in src:systemd, we use > > https://salsa.debian.org/systemd-team/systemd/-/blob/debian/master/debian/gitlab-ci.yml > > Yes, I'm using salsa-ci pipeline and quite happy with that :) > > However, it is just a workflow and best practice, not the infrastructure > that all of us should use for releasing packages, and you know we are > all human so sometimes make mistakes. > > I think if we can integrate piuparts infra for releasing packages, > we can avoid this kind of disaster and make sid users much happy, IMHO. > > dput -> queue -> build -> "piuparts test pass" -> repo > > > Is there any blocker to implement such thing?
it would be really cool to have a suite only containing packages that had their piuparts and autopkgtests pass. Oh wait, we already have that and it's called "testing". Why was #1021336 a problem? Because (for good reasons) many places use the "unstable" suite. These places (including the build infrastructure) use "unstable" instead of "testing" for good reasons. If you introduce yet another suite before packages land in unstable, then these places would likely want to use that suite instead, because they need to consume the most up-to-date packages. At which point you are back where you started. So shifting the problem to another suite doesn't help you at all because those pieces of our machinery that want to consume the most up-to-date packages will then use that suite and then still be affected by the problems you wanted to protect them from. So no, I do not think this makes sense. If some software is fine with older, but tested packages, then these software pieces can use "testing" today. Others have to live with the fact that the newest software is "unstable" for a reason. I think the right way to fix this is to find most of these problems that can be found by a machine before the upload happens. This can happen on the developer's machine but as our distro grows and we are testing more and more things (lintian, upgrades, arch:any builds, arch:all builds, reproducibility, cross building...) I do not think we can expect every developer to run all the tests locally for all packages they maintain. This is why I think using the salsa CI pipelines are a great solution to situations like this. In the spirit of this, i filed https://salsa.debian.org/vorlon/pam/-/merge_requests/14 Thanks! cheers, josch
signature.asc
Description: signature
