Contributing Developer - Florent 'Skia' Jacquet

Tue Jan 14 15:15:59 UTC 2025

Hi Skia!

Thank you for your prompt yet thorough response. It is greatly appreciated.

It is abundantly clear to me at this point that you are properly calibrated with Ubuntu's core philosophies and procedures, both technically and socially. You certainly exceeded my expectations for a response.

Given this, my vote on your application is a strong +1, and I would encourage the rest of the DMB to swiftly +1 as well. Responses inline.

On 1/14/25 06:18 AM, Florent 'Skia' Jacquet wrote:
> Hi Simon,
> 
> Thanks for your questions. Phew, that was a lot of homework, but please find my
> answers below:
> 
> 
>  > In your own words, what does it mean to be an Ubuntu Member?
> 
> In my eyes, an Ubuntu Member is someone who invests significant time to make
> Ubuntu thrive. That can take a lot of forms, from organizing Local Communities,
> to translation, graphic design, code review, end-user support, developer-support
> (patch pilot), etc...
> Since all those things generally involve somehow communicating with others,
> being an Ubuntu Member also means being part of a group, and all that comes
> with it. There is the CoC and it's required for every contributor to sign it,
> but when becoming a member, one should strive to embody it as best as possible.
> Too often I find it reduced mostly to "being careful of the language", but it's
> actually way more than that, with values of selflessness, rigor, care,
> empathy... I believe every Ubuntu Members should carry and spread those values,
> not only in the Ubuntu community, but in the world around them too.

I completely agree with this. In fact, in the Lubuntu Constitution, I did take a line from the CoC:

 > This document is not exhaustive or complete. It is not a rulebook; it serves to distil our common understanding of a collaborative, shared environment and goals. We expect it to be followed in spirit as much as in the letter.

It is critically important to understand that the CoC should not just be followed by the letter (pedantically), but followed in spirit by our actions and words.

I believe you understand this. Thanks.

>  > What is one thing you dislike about Ubuntu, or something think needs
>  > improvement, and why?
> 
> The tooling around packaging. Just to name three examples, there are way too
> many ways to:
> - build a chroot
> - build a package
> - proxy/cache the archive
> 
> It's not really about the package format, but really the many tools that
> come to fill those needs, and the lack of "standard way" that would be easily
> discoverable. Things are improving, like with the recent changes to `sbuild`, or
> documentation efforts like the `ubuntu-maintainers-handbook`, but there is still
> a lot of information around (wiki, random blog posts, ...) that's not always
> up-to-date, would describe things differently, and end up misleading people into
> using tools that haven't been maintained for years, but are still not really
> flagged as officially deprecated.

I am *very much* on board with this. That would honestly be very close to my answer if I were asked the same question today.

Please do reach out if I can help!

>  > What is your favorite part about Ubuntu, either technically or socially?
> 
> I don't like the concept of "favorite thing" in my life, so that one is quite
> hard for me.
> One thing at least that amazes me though, is the synergy between Debian and
> Ubuntu, where both benefit from the other. The two have managed to stay very
> much alive since the beginning of Ubuntu, without one taking over the other,
> and while still having quite different organizations and communities. They are
> alike, but very different, in many ways that I can't really explain just in that
> short text, and I find that absolutely fascinating.

Totally fair, and great answer. Debian wouldn't exist without Ubuntu, and Ubuntu wouldn't exist without Debian.

>  > Briefly describe which teams govern the (community) Ubuntu project as a
>  > whole, and when it is appropriate to escalate a concern to them.
>  > (Include sub-teams if you could, but a full list isn't required. Bonus
>  > points for how they're elected and by who.)
> 
> This question is best answered by starting with a tree:
> - sabdfl
>    - Community council:
>      - Membership board
>      - IRC council
>      - Matrix council
>      - Forum council
>      - LoCo council
>    - Technical board
>      - Developer Membership Board
>      - Ubuntu SRU
>      - Ubuntu Archive
>      - Ubuntu Release
> 
> There probably are a few more subteams, but the main ones should be there (I
> explicitly didn't mentioned the MIR team, since this is mostly a Canonical
> thing, rather than a plain community team).
> 
> Brief description:
> - sabdfl: Mark Shuttleworth, CEO+founder of Canonical and the Ubuntu project.
> - Community council: manages the social aspect of Ubuntu, and delegates to named
>    subteams for specific topics.
>    We should escalate there when there is a social topic that's not specific to
>    a subteam.
>    e.g.:
>    + Someone misbehaving on IRC, on Matrix, and on mailing list, with each
>      subteam already sending warnings. At this point the matter becomes more
>      general and should be handled by the Community council.
>    + A change such as a transition from IRC to Matrix, or the introduction of
>      Discourse. This is also not specific to a subteam, and I see that as mainly
>      driven by the Community council.
> - Technical board: drives Ubuntu from a technical perspective, and will discuss
>    architectural changes.
>    e.g.:
>    + If someone would want to discuss a change such as moving from glibc to musl,
>      or introducing systemd back in the time, the Tech board would likely discuss
>      these big fundamental topics.
>    + On the contrary, if a flavor wants to switch from lightdm to gdm, this
>      doesn't really require the Tech Board approval.
>    + If someone wants to introduce a new package to Ubuntu, then that's
>      technically the Tech Board's responsibility not to introduce unacceptable
>      code to the archive (bad license, virus, etc...), but that will actually be
>      handled by one of its named subteams: Ubuntu Archive.
> 
> Regarding the election, the governance page [1] specifies that the Community
> council and Technical board are named by Mark, and then the list is put to the
> vote of the Ubuntu Members, but that's more like a veto than a real election.
> Still, I have the impression that the last change of the Tech Board [2] didn't
> really follow that procedure, but instead relied on people self-nominating
> themselves, before the candidates were put to the vote, so that looked more
> like a proper election.
> I admit I might be lacking a bit on how exactly those instances are elected,
> given that I never got to participate to an election, because of lack of Ubuntu
> Membership (which is also partially why I'm applying in the first place :D).
> 
> It's worth mentioning that Mark keeps a certain right in each team's decision
> (by being the "dictator") but doesn't use this right lightly, and each subteam
> is named by its parent, instead of going through a proper election.
> 
> [1]: https://ubuntu.com/community/governance
> [2]: https://discourse.ubuntu.com/t/call-for-nominations-2024-ubuntu-technical-board/50081

If I'm being honest, I sometimes have to look up how some teams are elected. This answer definitely exceeds my expectations, thanks!

>  > Briefly describe the importance of the SRU process, the MIR process, and
>  > Feature Freeze, respectively.
> 
> Given that the question is mostly asking on the importance of the processes, I won't
> 
> SRU process:
> This is important because once an Ubuntu release is out, it becomes used
> by tenth of trillion of users (numbers are 100% accurate). Updating it then
> requires very careful procedure to avoid breaking the system, or simply
> introducing bugs, that could disrupt the use of an OS that's flagged as
> "stable". Even after the careful review, approval, verification, there's still
> the phasing of the update, to have more time to rollback should something wrong
> be discovered late in the process, and that phasing perfectly illustrate the
> importance of the process as a whole.

This will suffice; it would be nice to ask for phasing specifics, but meh, I asked for something brief so that's on me. :)

> MIR process:
> The archive is divided into four main pockets:
>           | Supported by Canonical | Supported by community |
> ---------+------------------------+------------------------+
> FOSS     | main                   | universe               |
> non-FOSS | restricted             | multiverse             |
> 
> The inclusion of a package in the `main` pocket must then meet a number
> of criteria both in terms of licensing, and quality of packaging + testing
> (including dependencies!), because those packages are flagged as officially
> supported, and nobody wants to officially support crappy software that's hard
> to maintain.
> The MIR process is thus here to ensure every package that enters the `main`
> pocket has been verified to match the criteria, but also that it has a team
> dedicated to maintaining it.

As a bonus question, what are the guidelines you can use to determine whether a package goes in Main/Universe vs Restricted/Multiverse?
(Hint, it's ~= the same answer I'd expect for Debian.)

> Feature Freeze:
> When approaching a release, it's important to get things settled to stabilize
> and fix bugs. If there was no FF, then that would mean stabilizing a moving
> target, and that's near to impossible. Every software needs to have a period of
> slower development before releasing, and Ubuntu is no exception to this.
> During this period, the automatic sync from Debian is stopped, and every upload
> needs to be justified by either a Feature Freeze exception bug, or should only
> contain bug fix, explicitly mentioning so in the changelog.
> These restrictions greatly reduce the number of uploads, and help actually
> having a "feature freeze", where few new feature are pushed to the archive, and
> more bugs are fixed than introduced (hopefully!).

Great answer, thank you!

>  > And lastly, why are autopkgtests so important?
> 
> Ubuntu is not actually one software, but an aggregation of many different
> softwares coming from many different development teams not talking to each
> other, and there is also the concept of software dependency in the middle, where
> one software needs another one to either build or run.
> In this regard, the role of Ubuntu is to integrate every moving piece together,
> and make sure everything works. If then nothing changes, the story could end
> here, but since software usually receives updates, then there are situations
> were one package update can break another package that happened to depend on
> it. If we introduce tests to packages, then we can start automatically verifying
> that a software works. This becomes more interesting if we systematically verify
> that a package still works after one of its dependency is updated.
> 
> That's the whole point of the britney + autopkgtest infrastructure, in both
> Debian and Ubuntu: automatically and systematically verify that the reverse
> dependencies of a new package still work before accepting it in the archive for
> general usage.
>  From a package maintainer point of view: the more dep8 tests there are in a
> given package, the more likely it is that the package will keep working as
> expected through all the changes of its dependencies (assuming someone cares
> about the tests results being green or red).

I was going to consider this correct no matter the answer. ;)

But yes, this is great. Thanks!

> Wow, you made it here, thanks for reading me, I hope this was interesting :-)

Yes, very much so! I don't remember the last time I have reviewed a Contributing Developer application, so for everyone else reading, don't consider this a "standard."

Thank you for everything you do!

Best,
-- 
Simon Quigley
simon at tsimonq2.net
@tsimonq2:ubuntu.com on Matrix
tsimonq2 on LiberaChat and OFTC
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/devel-permissions/attachments/20250114/54643d26/attachment-0001.sig>