Establishing Lubuntu Developers

[Simon Quigley]

Hello Robie,

On 2/12/19 5:17 AM, Robie Basak wrote:
> Hi Simon,
> 
> For reference for other DMB members, the process that Simon is
> requesting we use is documented here:
> https://wiki.ubuntu.com/UbuntuDevelopers/TeamDelegation

Yes, that's right; I didn't see it prior to sending this email but it
accurately describes what we'd like to do.

> On Mon, Feb 11, 2019 at 07:04:47PM -0600, Simon Quigley wrote:
>>                                                                 ...the
>> Lubuntu Council would like to propose the delegation of `lubuntu`
>> packageset upload permissions to the `~lubuntu-dev` team.
> 
> Thank you for taking the time to look after Lubuntu development process!
> 
> I'm curious: why do you feel that you need a delegation, rather than
> relying on the DMB to process applications directly? Is there anything
> we're falling short of in the DMB's non-delegatory process?
> 
> AIUI the delegation approval process doesn't require a reply nor any
> justification in itself, so to be clear I'm asking from a "how can we
> make things better" perspective rather than a "should this be approved"
> one. I'd like to better understand why delegation is useful to teams
> that use them.

Sure, thanks for the question.

It's not really a procedural shortcoming which prompted us to go for a
delegation process, it's more specific to Lubuntu Developers knowing
Lubuntu's infrastructure better. Specifically, Lubuntu has our own
Phabricator instance[1] where we do code reviews[2] and task
management[3] for the project, as well as code hosting[4] for the
packages we maintain. This is different from how Ubuntu processes are,
and while I fully trust the DMB to be able to evaluate the packaging
ability of a prospective Lubuntu Developer, code review and knowledge of
a candidate's ability to collaborate with other packagers on the
infrastructure we have set up is important as well.

This is similar to why Kubuntu has a delegated process; it's because
they have specific procedures as to how packages are laid out, a Jenkins
deployment to do automated builds[5] and a workflow for merging from CI
branches, as well as tooling which is specific to their
infrastructure[6]. The DMB could evaluate a prospective Kubuntu
Developer's packaging ability, but it is often times missing important
context about the workflow an actual Kubuntu Developer is expected to use.

This does bring up an important, wider point. If Ubuntu Core Developers
are expected to be collectively responsible for the packages that are
maintained by these subteams with different pieces of infrastructure, it
can be difficult sometimes to navigate the different workflows. We saw a
specific example of this in Kubuntu when Iain Lane expressed concerns
with the KDE autopkgtests. The solution involves fixing Kubuntu's
tooling to apply it to all packages, which are kept in our Git
repositories, so while Iain may have the upload access to do it (not
saying he would without talking to Kubuntu Developers), he wouldn't be
able to do it without stepping on toes unless he was familiar with the
processes. I don't know of an easy solution to these issues, but they're
worth considering.

Let me know if you have any further questions.

[1] https://phab.lubuntu.me/
[2] https://phab.lubuntu.me/differential/
[3] https://phab.lubuntu.me/maniphest/
[4] https://phab.lubuntu.me/diffusion/
[5] https://kci.pangea.pub/
[6] https://git.launchpad.net/ka

-- 
Simon Quigley
tsimonq2 at lubuntu.me
tsimonq2 on freenode and OFTC
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/devel-permissions/attachments/20190212/b5c3d636/attachment.sig>