Granting PPU permission on "core" packages

[Robie Basak]

On Mon, Jul 22, 2024 at 06:11:27PM +0100, Robie Basak wrote:
> Then we end up discussion what criteria is appropriate to consider for
> such a PPU application. Is PPU appropriate for such packages at all, or
> do we need something else? Alternatives might be:
> 
> 0) PPU is fine for this situation.

I suppose a followup to this would be: what criteria would we use to
decide PPU in such a situation? Should our expectations be the same as
for any other PPU, such as seeing some uploads and endorsements, or
would we expect to see evidence of a deeper understanding with other
packages?

When I follow this line of thought, I find myself wanting to see many of
the things I want to see from core devs. Not necessarily because any
specific item in my list is appropriate criteria, but because I see
dubious uploads happening elsewhere in the archive from developers
uploading without supervision, and I don't want to see that happening
with such key packages. What criteria can we really set that is
objective? I don't have a good answer, but equally I'm not keen on
someone who has had only narrow experience having this kind of
unsupervised expectation on them.

> 1) Require the applicant to get core dev instead, since widespread
> understanding of operations across the archive is an appropriate
> prerequisite.

I'm increasingly leaning towards expecting developers to have access to
make unsupervised uploads to key components having "done the rounds"
across the archive. You can pick particular items of experience and
point out how they aren't necessary for a given PPU request, and I
accept that. However I don't think that invalidates the idea that having
broad experience helps with package upload quality, and that touching a
wider range of things apart from just a narrow specialised area results
in getting that broader experience. One might be concerned about the
burden on prospective developers to be able to upload these packages,
but these requests have been coming from Canonical employees, I don't
think there'd be a problem if the DMB were to conclude that these things
need widespread experience and expect Canonical employees to get that
experience first. As long as there were a well defined path to follow.
Because the work to develop that experience needs doing anyway.

> 2) Find some other way to make this work without applicants having to
> demonstrate widespread understanding across the archive. Some ideas have
> floated around on transitioning to a peer-review based system, rather
> than the "grant unsupervised permission to upload a subset of the
> archive by package" that we currently have. But such a transition would
> have to be driven by someone working with or inside the DMB,
> establishing consensus, and actually doing the technical ACL
> implementation, to make it happen.

The suggestion was that you'd join a reviewers team that is parallel to
the existing teams (core dev reviewers, MOTU reviewers, server
packageset reviewers, etc). An upload would require a peer review from
somebody else in that team. Joining the team would require demonstrating
a track record of high quality *reviews*, rather than uploads.
Eventually the original teams would be deprecated and replaced entirely
by the peer review teams.

I really like this idea and would like someone to drive making it
happen.

However, I'm not sure it completely solves the problem, since I'd want
to see a PPU applicant doing reviews of similar PPU work, and then to
what criteria do we consider those reviews? Then we're back to the
original question.

Having said all that, I'm open to having my mind change on this. I think
it's more important that the DMB make a decision, so then we can move
forward with a path to unblock these applicants.

Robie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/devel-permissions/attachments/20240722/47cffa0e/attachment.sig>