Maytham Alsudany <mayt...@debian.org> writes: >> 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:
Yeah I also find multiple issue per package confusing. With one issue per package, it is easy to add comments to the issue explaining what has to change, and to discuss those changes. The top-level summary can also be updated to summarize current status. > - open = not in the archive yet > - closed = in the archive / abandoned > - tag "passed-review" > - tag "accepted" when the package enters the archive Right, tags can be used to even further summarize things. > 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). +1 > 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". +1 > And if the table in README is still necessary, then (I think) a CI > pipeline can update it from the issue data. Doable, but I'm not sure that complexity adds anything. >> 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"). +1 -- that is the responsibility of the main Salsa pipeline, I think. > Let me know how I can help! I enjoy reviewing copyright files, so if any > arise, please send them my way :) I hope that we can find some problem to fix in the `litetlog` packaging when I submit it, arguing for the awesomeness of this effort :) /Simon
signature.asc
Description: PGP signature
