On Sat, Mar 30, 2024 at 10:56:40AM +0100, Iustin Pop wrote: > > Now it is time to take a step forward: > > > > 1. new upstream release; > > 2. the DD/DM merges the upstream release VCS into the Debian VCS; > > 3. the buildd is notified of the new release; > > 4. the buildd creates and uploads the non-reviewed-in-practice blobs "source > > deb" and "binary deb" to unstable. > > > > This change would have three advantages: > > I think everyone fully agrees this is a good thing, no need to list the > advantages. > > The problem is that this requies functionality testing to be fully > automated via autopkgtest, and moved off the "update changelog, build > package, test locally, test some more, upload". Do you mean this theoretical workflow will not have a step of the maintainer actually looking at the package and running it locally, or running any building or linting locally before pushing the changes? Then yeah, looking at some questions in the past years I understand that some people are already doing that, powered by Salsa CI (I can think of several possible reasons for that workflow but it still frustrates me). > Give me good Salsa support for autopkgtest + lintian + piuparts, and > easy support (so that I just have to toggle one checkbox), and I'm > happy. Or even better, integrate all that testing with Salsa (I don't > know if it has "CI tests must pass before merging"), and block tagging > on the tagged version having been successfully tested. AFAIK the currently suggested way of enabling that is putting "recipes/debian.yml@salsa-ci-team/pipeline" into "CI/CD configuration file" in the salsa settings (no idea where is the page that tells that or how to find it even knowing it exists). -- WBR, wRAR
Attachment:
signature.asc
Description: PGP signature