Contributing Developer - Pragyansh Chaturvedi

Mon Mar 17 20:00:13 UTC 2025

Hi Simon

On Sun, 16 Mar 2025 at 20:32, Simon Quigley <simon at tsimonq2.net> wrote:
>
> Hi Pragyansh,
>
> Sorry for the delay on reviewing this. I have a few questions and notes inline.
>
> On 3/11/25 02:20 PM, Pragyansh Chaturvedi wrote:
> > Hi
> >
> > I want to apply for Ubuntu Contributing Developer.
> > My application:
> > https://discourse.ubuntu.com/t/pragyansh-chaturvedi-membership-application/56907
>
> (I actually prefer Discourse over the wiki personally, thanks for this.)
>
> > Though I have reserved the DMB meeting slot on 12 May 2025 (1900 UTC),
> > I request the DMB to consider treating this application asynchronously
> > on this mailing list as I live in GMT +0530 (APAC). The DMB agenda is
> > completely packed for the next 2 months with people applying for
> > upload rights. I am not applying for any upload rights right now, so
> > this can be done on the mailing list. However, I am fine if the DMB
> > still insists on an IRC interview.
>
> This seems reasonable. Just note, to you or to anyone else reading, email applications *can* be somewhat more intense. Just be mindful of that (benefits and tradeoffs.)
>
> I will also tailor the questions to the applicant. While "using your resources" and reading emails like this to get answers is a great idea, it may only help so much.
>
> > The updated agenda page: https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda
>
> I noticed this and noted it specifically to make sure we bring it up at the DMB meeting tomorrow. Thanks for that.
>
> Okay, my questions. Just for some brief context, I spent more than one term on the Ubuntu Membership Board and this is my third term on the Ubuntu Developer Membership Board.
>
> As such, my questions (and thus my personal standard for granting these permissions) is a mix of social and technical questions. I'm not asking for perfection, all I'm asking for is your best. Please do take your time.
>
>   - Your work on the Raspberry Pi stands out, as does Dave's endorsement. Where do you see the "Ubuntu on Raspberry Pi" story going in the next five years, generally speaking?

I see Ubuntu on Raspberry Pi achieve parity with RaspiOS. There are a
lot of things that one can do on RaspiOS but can't on Ubuntu. A couple
of months ago, the camera stack didn't work on Ubuntu - which was a
bad look as we have a device with 2 camera ports (Raspberry Pi 5), but
Ubuntu couldn't take advantage of them. There are a bunch of HATs
which work out of the box on RaspiOS but won't work on Ubuntu.
I want to see the work we do for Ubuntu on Raspberry Pi help the user.
Ideally, they shouldn't be expected to read 2 sets of documentation,
so things any Raspberry Pi-specific things (like HAT or external
device support) which work on RaspiOS should work on Ubuntu pretty
much the same way. Everything that RaspiOS allows a user to do should
be possible on Ubuntu with the same amount of effort (or less). This
makes Ubuntu a better option over RaspiOS, as they can use the same
Linux distro across their PCs, servers and Raspberry Pi. Porting their
work from RaspiOS to Ubuntu would also become fairly straightforward.

>     - Is there anything you are particularly looking forward to, or an upcoming challenge that seems particularly difficult?

I will talk about the challenges here, as those are the things I am
looking forward to solving.
The first is ensuring we don't cause a regression in other devices
while trying to enable anything new for the Raspberry Pi. RaspiOS does
not have this problem as they have a smaller set of devices to care
about, but we don't have this luxury.
The maintainers at Raspberry Pi don't quite abide by the packaging
best practices. So when we port those packages, we need to fix that.
Some things in the Raspberry Pi ecosystem are closed-source. For
example, the imx500-firmware for the AI camera does not have an
open-source license, so we are unable to get that in Ubuntu at the
moment. Similarly, the packages for the Raspberry Pi AI HAT+ are
closed-source as well, and we would need to find ways around it.

>   - What is the significance of Launchpad karma? Does any membership board in Ubuntu use it as a deciding factor for membership? If so, why? If not, why?

Launchpad Karma is an indicator of a user's activity on Launchpad. You
earn it through various interactions on Launchpad, and it decays over
time.
But I feel that's it. It is just an "indicator" and not a metric.
While I think Karma is a better system than Github's Green Wall, it
still has that problem of rewarding quantity over quality.
Karma is not a metric that dictates the impact a user has on the
community. People who work with hardware vendors to integrate Ubuntu,
people who contribute artwork for Ubuntu, and people who help
popularize Ubuntu in educational institutes might not have a huge
amount of Karma, but they can still be considered for membership
(Though maybe not all Boards would do that)
A very low Karma might be concerning (something in double digits
perhaps, as you should have sustained contribution over the last 6
months for applying to a membership). So, one can argue that someone
with a Karma of 6000 is more active in the community than someone with
a Karma of 52. But this argument falls flat if we start comparing a
Karma of 1000 to 6000 or 10000. In that case, we must have a
subjective and qualitative look at the contributions and what the
individual brings to the community instead of stressing over
quantitative stats.
A critical security bug fix might provide the same amount of Karma as
any other fix, but that contribution can be considered very important
and comparing or using Karma as a benchmark might be unfair in such
cases.
I haven't encountered any membership board using Karma as a deciding
factor in the wiki yet, and I believe it is for the reasons I gave
above. This is just an indicator of activity, and giving too much
importance to it (and considering it as a metric for membership and
upload rights) would result in people trying to find ways to farm
Karma

>   - Granting you membership as an Ubuntu Contributing Developer would implicitly grant you Ubuntu Membership. In your own words, what does it mean to be an Ubuntu Member, and why are you seeking these permissions in a social sense?

I am applying to be a Ubuntu Contributing Developer as a progression
checkpoint. I am working my way towards MOTU, and I am to gain PPU
rights for the raspi packageset. I see being the Ubuntu Contributing
Developer as a first step towards this (even if it may or may not be
required). I figured that I probably fulfilled all the requirements,
and applying for it would make me comfortable with the whole
application process for my future applications. This will help me be
sure that I am probably on the right track and make me feel more
included in the Ubuntu Developers' ecosystem.

>   - Briefly, what is the significance of the Ubuntu Main Inclusion Request policy? I noticed you have filed more than one MIR; which one has made the most impact, or alternatively, which one was your favorite?

The Ubuntu Main Inclusion Request policy is the process Ubuntu follows
to promote packages in universe to main. Packages in main are
recommended and better supported by the Ubuntu community than packages
in universe. Packages in the main repository are considered the most
popular and reliable option for their application. So the requirements
for a package to be included are very strict. There should be an
extensive testing plan for the package (preferably automated). It must
not have a history of concerning security issues (or might be so
indispensable that we still have to carry on with it). There must be a
very good reason to promote a package, as a big list of main packages
will pose problems for the maintainers.
My favourite one would be nlohmann-json, and the reason is that this
is a library I used a lot before contributing to Ubuntu. For me, it is
the de facto JSON library for C++. I was quite surprised that it is
not actually in main (the alternative in main was Boost.JSON). So
instead of very straightforward reasons for my other MIRs (replaces
old package in main/new dependency of something already in main), I
had to make a case of how popular this library is and how extensively
it is used, and we can not convince many upstream maintainers to
change their JSON library (when some of those projects are actually
quite sizable and can be future MIR candidates)

>   - I understand this application is not for upload rights. That being said, I am noticing several source NEW packages, which is a green flag for me. Could you briefly describe what you've learned about preparing brand new source packages?

The first thing I do is to figure out how to get the d/copyright. I
use Config::Model for it. This can be a bit arduous as all the tools
like cme or licensecheck might have some gaps to fill in in the
generated copyright file, and then you need to check out all the
problematic files' SPDX headers. Then you need to have a d/control
file which lists all the hard and soft dependencies, all the packages
or binaries a certain project will create. We have a d/rules where me
have to tell how to build and install the project using debhelper, and
can override any step in it. We have a d/watch, which is used to watch
out for new upstream releases. It should point to a source where
regular releases are published (A git mirror, gitlab, github,
sourcehut). We have d/patches with all the patches we need to apply
over the upstream release, and a series file which tells the order in
which the patches must apply. The patches should ideally have a DEP3
header.
We then have *.install files, which tell us which files belong to
which binary/package and where they are installed (usually, the
package/binary name is the name of the *.install file, but not
necessary). We also have *.manpages files, which are basically
*.install files, but for the manpages. There is also
*.lintian-overrides, which we must not have because overriding lintian
is frowned upon. We must obey lintian.
Then there is d/changelog, which has the changelog history in a
machine-readable format (even the copyright file is machine-readable).
Also, we can specify the exclusion of some files in d/copyright (had
to do this once as one of the projects I packaged had the infamous
lena.png as a test file).
We have d/tests for )autopkgtests (very important for MIRs).
d/t/control has a whole page dedicated to it about the various options
and capabilities we can run tests with -
https://people.debian.org/~eriberto/README.package-tests.html
This reminds me that the script written in d/rules is not executed in
a single shell sequentially; every new line is executed in a separate
shell. I was rattled by this finding while trying to fix a bug in
bpftrace.
I think I glossed over d/control. It also has Standards-Version for
lintian and has a bunch of metadata about packages. It also lists the
dependencies and any version conflicts a package might have (or
requirements). It lists the build dependencies, runtime dependencies,
and the recommended dependencies.
Then there are d/source/format and d/soruce/options, which control how
the patches are applied. I have only ever seen 3.0 (quilt) in format,
though.
I have made use of debian/source/include-binaries a lot, though,
mostly to add test files for autopkgtests as a compressed archive.
Then there are the postinst, preinst, prerm and postrm files, which
are used for doing stuff like preinstall checks, adding permissions
and starting services post-install, and removing users, permissions or
shutting services post-removal.
We also need to provide a symbols file (or multiple ones for different
arches) if the package comes under the LIbs section.
Then there are a bunch of files that debhelper generates, like
debian/files, substvars... but I don't know much about them (substvars
are used to substitute the variables used in d/control, which I have
seen being used while listing dependencies, like ${misc:Depends})
Now, I also test the d/watch file using uscan. We can also add a
suffix to the upstream version using d/watch (I did it in the lena.png
example, where I suffixed the version string with "+nolena")
Then I run lintian --pedantic to see if there is something very wrong
that lintian might complain about, and I work to fix that.
Then I use rebuild (and occasionally build) to check the build and
install process, and the package is ready for being uploaded to a PPA
(and requires a [needs-packaging] bug against Ubuntu on launchpad)

In the end, I try to follow https://www.debian.org/doc/debian-policy/index.html

>   - What is your favorite thing about the Ubuntu project, socially or technically, and why? (If you prefer not to answer with the word "favorite," you may replace it with something along the lines of "most fascinating aspect.")

I like how versatile Ubuntu is as an OS. The spectrum of potential
users is too wide - from people who just want to read their emails and
stream movies to full-time developers and server workloads. I struggle
with other mainstream OS and distros - I can't use macOS, and I lose
all my computer skills as soon as I am handed a Mac. I don't like
Windows because of how bad the C and C++ development and debugging
experience on Windows is (I only use it for gaming and using IDA, both
of which I haven't touched in months now as I just run them on Ubuntu
using Wine now).
Also now that I am somewhat involved in Ubuntu, I can fix bugs in
packages which I use and encounter. If something doesn't work, I know
where to find the source and try to debug it (if I am willing to do
it). That is something I can't do with other mainstream OS.

>   - What is one thing you dislike about the Ubuntu project (or something generally needing improvement), socially or technically, and why?

Something that needs more improvement is gaming on Ubuntu. I usually
like and play very old games (the SNES and GBA games are a sweet spot
for me), but that is partly because I grew up with underpowered
computers (and there are some real masterpieces from that era that I
enjoy).
So when I have to play Windows games on Ubuntu, I must use Wine or
Lutris. The problem with these solutions is that they have a very
ad-hoc approach to supporting games (you need to recompile wine with
this patchset to make XYZ game work).
I don't find a lot of things to dislike about Ubuntu, but one thing I
wish was better is the gaming ecosystem. Valve has some great work put
into their Proton project and the Steam Deck (which runs on SteamOS
based on Arch), so gaming on Linux is not an unsolved problem. I am
sure that we can come up with a snap-based solution where games can
specify what version of Wine/Lutris/Proton they work with and what
patches or compile options need to be applied. So they come with their
own emulator if a suitable one is not present on the machine. We can
have such a launcher on Ubuntu, though I think we will have to get
Valve involved, too, if we want this integrated with Steam, and that
can be quite tricky.

>
> As a general comment, you are well on your way to MOTU, in my opinion. Keep up the great work. :)
Thanks!

>
> Hopefully we can formally vote to review your application over email tomorrow; if I were you, I'd either lurk in the meeting or read the logs afterwards; and adjust accordingly.
>
> Warm regards,
> --
> 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

Best regards
Pragyansh