On Sun, 2024-07-07 at 11:32 +0200, Niels Thykier wrote: > Soren Stoutner: > > After reading a number of comments to the email below, I thought I would > > provide a bit of context for this email and Phil’s excellent work on > > Mentors. > > > > Recently Phil has taken it upon himself to triage every package that > > requests > > sponsorship on mentors.debian.net. Here is an example of the work he does: > > > > [...] > > Hi, > > I wholehearted agree that Phil is doing a lot of good work here and that > it is helpful to all parties involved in d-mentors. From my PoV, what > Phil does is so valuable that ideally we would provide it to all > sponsored maintainers with minimal latency. For me, that means > automating most of what Phil does. Ideally all, but I am not sure all > the things Phil does are trivial to automate where we are now. >
Many thanks. > > But I have found Phil’s work to be very helpful, as I have limited time to > > handle sponsorships. When I look at a package Phil has endorsed, I can be > > sure that the simple and obvious things have already been taken care of. > > > > Thinking a bit more on this and its long term sustainability, I think we > have a spot here where we could automate the process a lot. If we look > at the list of things Phil does: > > 1. Build: > > Automate-able if we had good sandboxes/throw away build machines. > > 2. Lintian: > > I think mentors.d.o already does this. But it only works on the > artifacts uploaded and Phil probably enriches this. > > 3. Licenses: > > While ideally, we would want this to be automatic, I think we do not > have a good solution to this and I doubt we get it any time soon. > > Though an 80/20 might be in our grasp for someone interested and > I do not think it would need to depend on 1). > > 4. Build Twice (sudo pbuilder build --twice <package>.dsc): > > Automate-able once 1) is solved. > > 5. Reproducible builds (reporotest): > > Trivially automate-able once 1) is solved. > > 6. Install/Upgrade: > > It sounds like something piuparts would check, so I assume this is > all solvable once 1) is complete. > > 7. Curating packages that pass these checks to various prospective > sponsors (such as the mail we are all replying to) > > These automations would not replace Phil since Phil in "failure" cases > provides suggestions on how to move forward. This part we would ideally > automate as well, but that is a much harder problem for most of these > checks. Still, having a "red/green" marker would enable newcomers to > figure out where they need more effort or assistance. > > The salsa-CI pipeline basically does most of these (3+7 being very clear > exceptions, do not remember if 4 is covered by salsa-ci, but adding it > would probably easy) and that infrastructure already has "no trust" code > execution flows. Another alternative might be leveraging debusine if > that can do the same and is intended for this purpose (did not check). > > In theory, we can reduce this to a already solved problem by linking the > RFS/mentors entry with the relevant CI pipeline report where possible > and a "Consider using the salsa-CI pipeline" check. Might need > tag2upload or dgit (assuming these support mentors.d.o), since that > would make the commit visible. Additional bells and whistles can be > added to the salsa-CI pipeline in the form of a small machine readable > report output that mentors.d.n could render if necessary (etc.) > > I do think it could be a major improvement our sponsorship work flow for > both sponsors and sponsored maintainers. > > 1) We promote a streamlined packaging workflow that a large portion of > Debian already follows and leverage existing infrastructure. Any > updates to our workflow would appear into the sponsor workflow > checklist workflow because they are the same underlying checks. > > 2) The workflow provides most of these checks with low latency > automation and would save the sponsored maintainers RFS + > mentors.d.o upload round trips. > > 3) The process would be a lot more sustainable, since most of it would > be automatic. > > Obviously, on paper is doable but it might require ironing out a lot of > bends or even not be possible at all. Sadly, I am not volunteering to do > it (got too much on my plate already). However, I am putting the idea > out there in case someone has time and interest in working on this area. > > I think the primary risk (problem to solve) is linking the mentors.d.o > upload to a git commit on salsa and the related pipeline data for that. > As said, I hope tag2upload/dgit could be part of the solution here (not > sure how those will cope with mentors.d.o versions being a lot more > mutable than regular uploads). For everything else, I think most of the > heavy lifting have already been done and "just" a matter of gluing it > all together. > Being partially or fully automated is fine by me. :-) I would be happy to assist those who embarked on such a project. There is always work elsewhere in Debian like the QA Team that I have interest in. <snip> Regards Phil -- Internet Relay Chat (IRC): kathenas Website: https://kathenas.org Instagram: https://instagram.com/kathenasorg/ Buy Me A Coffee: https://buymeacoffee.com/kathenasorg
signature.asc
Description: This is a digitally signed message part
