On Wed, 2025-03-12 at 09:52 +0900, Charles Plessy wrote: > I have just drafted a workflow in > > https://salsa.debian.org/newgateway-team/reviews#how-to-request-or-make-a-review > > which I quote here: > > 0. (We are in pilot phases. Improvements of this workflow are welcome) > > 1. The package maintainer adds the > [pipelines](https://salsa.debian.org/newgateway-team/pipelines) to its > Salsa CI > file. (It would be cool to have a _devscripts_ script for that.)
I like the idea of pipelines that only create artifacts, without creating a pass/fail result that affects the package's overall CI. > 2. The package maintainer opens an issue with _Review_ template (shall we > just make it default?). Salsa ID pings in the issue can be useful for > exchanging reviews. > > 3. Once the checklist is clear, the maintainer uses the create merge request > button in the issue page, to add the package in the table below. (Or > just > editing the file directly is fine?) Wouldn't using an issue's open/closed status and tags be sufficient rather than MRs for each issue? For instance: - open = not in the archive yet - closed = in the archive / abandoned - tag "passed-review" - tag "accepted" when the package enters the archive I also suggest using a standard naming scheme like "package/version" (e.g. "r-cran-multitaper/1.0-17-1") for easy lookup of packages as well as different versions (for binNEW). Then, if ftp-masters want to check for a peer-review, they can just look for the name of the package in the list of open issues, named with a standard "package-name/package-version". And if the table in README is still necessary, then (I think) a CI pipeline can update it from the issue data. > 4. Somebody merges the request after verifying quickly that the checklist > was > properly addressed. > > 5. Reviewers open issues with the _Review_ template. If problems are found, > they ping the maintainer with their salsa ID in the issue discussion. > Reviews > end by adding the issue ID in the table below via a MR to be accepted and > merged by the package maintainer. > > 6. Once all reviewers thumbs are up, update the table below (with or without > MR), and upload to NEW. > > 7. Once the package leaves the NEW queue, record the outcome in the table > below. Some definition of scope would be useful (e.g. "we don't check if the program runs or if the package builds (that's the responsibility of the uploader), we just do the same checks as those that happen in the NEW queue"). Let me know how I can help! I enjoy reviewing copyright files, so if any arise, please send them my way :) -- Maytham
signature.asc
Description: This is a digitally signed message part
