Kernel DKMS PPU rights

[Robie Basak]

Hi Brett,

On Wed, Apr 30, 2025 at 09:16:07AM +1000, Brett Grandbois wrote:
> As you know, two members of the Canonical Kernel Team recently applied
> for kernel-dkms PPU and both were rejected. In trying to determine the
> next steps to get them (as well as others) on a path to better
> preparation, we have come to realize that we are not able to find any
> clear requirements for the access rights.

In general, my view of the the DMB's role is to measure applicants
against best practice knowledge, skills and behaviours as established by
Ubuntu developers in general. Unfortunately these aren't well
documented. I think that's the responsibility of Ubuntu developers in
general rather than the DMB specifically. The packaging guide and
maintainer's handbook have exhibited progress in this direction, but
there are still big gaps.

If I turn down an applicant at a DMB meeting I take great effort to
ensure that I present an objective way forward. I suggest looking at
previous meeting logs to identify gaps in existing documentation on
those expectations.

In response to your email I've also taken the opportunity to improve the
documentation I have on my personal expectations. I've added paragraphs
on my expectations around communication and endorsements, and
generalised the text to all applications rather than core devs
specifically. The new link is:
https://wiki.ubuntu.com/RobieBasak/DMB/Expectations

Prior to my departure from Canonical, James and I also worked on a
"syllabus" for Ubuntu developer training. That's currently an internal
document I no longer have access to. I don't think it contains anything
confidential, though, so if you could make that public, I'd appreciate
it! I had aimed it initially at core dev applicants, but for DKMS PPU,
an appropriate subset would apply. If future DKMS PPU applicants were to
fulfil those items, I think they'd have more success.

From memory, in relation to the recent unsuccessful DKMS packageset
applicants, I'd like to make some observations. The applicants didn't
seem to have a clear picture of the normal lifecycle of these packages,
including processes around merges. These are as much a team
responsibility as they are individual knowledge items. It did seem like
their team was letting them down here. Quality of existing uploads was
poor, as sponsored by existing uploaders. Again, it seems that their
team was letting them down here.

I'm all for better documentation of expectations on these items. But I
would note that in the past, these were simply part of Ubuntu
development culture. When I first applied for upload access myself, it
was a given that I should know these things, and all applicants
generally did. Now, that seems to have changed. I think this is perhaps
due to growth, with individual specialists working increasingly in silos
with respect to other Ubuntu developers. Turning culture into
documentation is a vast effort. We might well have grown to the point
where that documentation is now needed. But, as above, I don't think
this is solely within the scope of the DMB's responsibility.

I imagine that you might find this frustrating: I'm referring to
expectations but not specifying them. I appreciate the difficulty of
that situation. Of all the people involved, I feel that I've been doing
much of the heavy lifting to fix this, for years, so please don't blame
the messenger! The best I can offer right now is that there are a
significant number of Ubuntu core developers who *do* understand these
expectations, and we should use their knowledge and experience to help
prepare others. But recent applicants, especially those employed by
Canonical, seem to not be being trained by them - that's something that
I think needs fixing internally within Canonical.

> Following on, as DKMS seems to be a more refined case of the existing Kernel PPU, I’d like to start exploring an application for a Kernel DKMS PPU delegation (https://wiki.ubuntu.com/UbuntuDevelopers/TeamDelegation). Is this something we could do, similar to other existing delegations? What do we need to do to get there? Again, any further guidance would be greatly appreciated.Thanks,Brett

Since my view is that the team in general (rather than just recent
applicants) isn't currently following Ubuntu development best practice,
I'm -1 on granting a delegation right now. I'd be happy to see that
change, though!

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/20250521/1f5c0dd4/attachment.sig>