Hi,
Quoting Hideki Yamane (2022-10-07 03:39:39)
On Thu, 6 Oct 2022 17:45:06 +0200 Michael Biebl <biebl@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
--==============‘07415420381968164=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEElFhU6KL81LF4wVq58sulx4+9g+EFAmM/8pUACgkQ8sulx4+9 g+GHJQ//bdBkHZI5rAoH1ArRh7bPJoL/HB9GbCUSkYmsDWBTgLO2rHJnGL2jr81M geLl8rmPsUZSm3Uom8b/aR1noGk84wvhTe1N0g61D66GRfvUI/x2olWDH7kVqU7y RXx2/qe7fU9dr+lTgE8XTitPrQTeWq82U/R6g4e271eeQ1RarKl3kTBnc6YiTqOM hbwB7bSO1lxPcQOH6XVdYyy9yMJo2VFJ9mVZC49IygfCd6OdtsFojiffS9VMJ39d ijlIKSfgjZ72z1rtltx34r5BewDtoydlGtZ5F5ItTyfLX0lUhU88Qh5haK2gwTv/ kXTOd1s4IGNWzgPi/oEc2sAKe7ZeCpi/ziO3I8PB7WwuNGmw0de5H6h58NsQ7SFq VjOY+GvAOooINtAmnhhAouXvV6hI463O3saqJPX/QV4TzQg2pJBajyPrdAK+Z4oV akzMy3i12FWccbgFJ0M6xf1yr2OfPiajSiMHE2fPXJUlM5Eavp+wlletUYJqCQtq 3HyeB5s4Ycw2Je0NU/kF7NDsQhmImJpzexYdxFkNTN2AIkQ//5WLN06Wm7y8G1Go Sjb2E2dp0n/JZkxq5NPS+gIvTw0+Rwf+ROrGV3FI3O9DOU0+/dCMRJyo65OqslOW Q45W4GbNcG3DeGKuTXsrfBJmA3NRI90cjvC+dTU0t7U+nfv/PKw=
=LjfX
-----END PGP SIGNATURE-----
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)