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.
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.
I would heartily hope that Phil continues to send periodic emails to debian-
devel with lists of packages that he considers ready, but that are languishing
on the vine because nobody has noticed them.
Agreed.
[...] There is probably nothing as demotivating to a first-time
contributor as putting a lot of effort into a package, having it be in good
shape, and then never having it be sponsored simply because it didn’t get
noticed.
Soren
Agreed; feedback latency is quite a de-motivation factor for me as well.
P.S. Based on Phil’s work on Mentors and my interactions with him, I have
advocated for him to become a Debian Developer, uploading. I think his
contributions to Debian will be even more impactful when he can sponsor the
packages he feels are ready.
https://nm.debian.org/process/1305/
[...]
Thanks for supporting Phil. :)
Best regards,
Niels
