Contributing Developer - Florent 'Skia' Jacquet

[Florent 'Skia' Jacquet]

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.


 > 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.


 > 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.


 > 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


 > 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.

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.

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!).


 > 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).



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

Skia