Contributing Developer - Pragyansh Chaturvedi

[Pragyansh Chaturvedi]

Hi Simon

On Wed, 19 Mar 2025 at 01:10, Simon Quigley <simon at tsimonq2.net> wrote:
>
> Hi Pragyansh,
>
> My vote on your application is a conditional +1. Comments/conditions inline.
>
> On 3/17/25 03:00 PM, Pragyansh Chaturvedi wrote:
> > 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.
>
>  From a user perspective, this is something I can see as well. Solving remaining, major inconsistencies between Ubuntu and RaspiOS seems great.
>
> Thanks.
>
> >>      - 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.
>
> Without having done a review of the specific packages at hand, this may be a case for the Restricted pocket.
>
>  From the perspective of Lubuntu, I do wish RaspiOS would switch to LXQt instead of attempting to keep LXDE alive.
>
> I agree on the specific technical points (generally, only having taken a brief look at it) but have specific comments on the sentiment below.
>
> >>    - 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
>
> Great, thanks!
>
> >>    - 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.
>
> You are correct that it is an optional step towards MOTU, but I'm not seeing specific information on what it means to be an Ubuntu Member in a more social sense.
>
> To fill in the blanks, Ubuntu is more than the code and precise technical bits that make everything work well.
>
> We have artists, translators, UX designers, QA testers, people who provide end user support, and more. Becoming an Ubuntu Member would mean that you are a part of that collective group.
>
> One of my conditions on a +1 is answering this followup question, more specifically...
>
> In your own words, what does it mean to be an Ubuntu Member in a social sense?

Being an Ubuntu Member would mean being a part of a group of people
who have shared ideals (to a large degree) about open-source software.
Being involved in maintaining and growing a project I largely
benefited from and collaborating with people who share my thoughts
about this project is a great perk. I will also gain a sense of
belonging, being a member of something that affects a lot of people
around the world in a positive way. I see Ubuntu as a user-centric
project, and I want to be identified with it and the community that
makes it a possibility.

>
> To give you credit where credit is due, it is an excellent idea, and I wish more people would take this route. Being comfortable with the application process is important.
>
> Generally speaking (not just to you but to anyone reading) I will add that, if any potential applicant would like feedback from the DMB before submitting their application, we are happy to provide it.
>
> I think it's valuable to generally reiterate that the DMB is an elected body; we don't just make decisions on applications, questions are welcome. Preparedness is a green flag, not a red one.
>
> >>    - 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.
>
> Great, thanks.
>
> > 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've actually used nlohmann-json in a C++ project recently, thank you for your work on that!
>
> >>    - 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
>
> This absolutely exceeds my expectations for an Ubuntu Contributing Developer. Great work.
>
> I'll add a trick that I originally heard when I became an Ubuntu Developer myself:
>
> "All sponsors are evil and pedantic."
> That's obviously cynical. I much prefer:
> "Some sponsors can be evil and pedantic."
> Which translates to:
> $ lintian -EviL +pedantic
> Or, if you don't want to go through lintian.debian.org (for some extra verbosity):
> $ lintian -EvIiL +pedantic
>
> Fixing all Lintian errors everywhere isn't mandatory, but... it is very much best practice, in my opinion. I understand some other DMB members believe it's more trivial.
>
> >>    - 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).
>
> This is a fair, honest response. That being said, I disagree with the sentiment, in a way.
>
> Windows, Mac OS, FreeBSD, and others are alternatives to Linux, this is certainly true. I would caution you against alienating those people even slightly, though.
>
> We now have Ubuntu on Windows via the Windows Subsystem for Linux, and many people run Ubuntu virtual machines on other operating systems.
>
> I am not here to police your opinions or your expression of those opinions, you are entitled to those, but I do have a question which is part of my "conditional +1"...
>
> If granted membership as an Ubuntu Contributing Developer, do you agree to set any personal opinions aside to work towards common solutions across different communities, when the opportunity presents itself?

Certainly. I will abide by a "user first" approach when contributing
to the project, as I have already mentioned in the answer to the first
question. I used Ubuntu on WSL for 3 years before committing to Ubuntu
Desktop (this was largely due to disk space constraints and to share
folder contents) as my daily driver (and I think it is one of the best
ways to gradually ease into the Ubuntu ecosystem - when you might not
have multiple machines and resources and don't want to fully commit to
it due to various reasons), so I am up for bridging gaps between
communities if this is ultimately beneficial for the users. I didn't
mean to alienate other communities while describing what I like about
the project in the original answer.

>
> > 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.
>
> Great, thanks.
>
> >>    - 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.
>
> It might be worth getting in touch with some of the upstream folks and using the snaps, some great work has already been done on that front.
>
> That being said, I appreciate the enthusiasm on this front. I would personally appreciate being able to play the original SimCoaster game again.
>
> >> As a general comment, you are well on your way to MOTU, in my opinion. Keep up the great work. :)
> > Thanks!
>
> Thank *you*. :)
>
> 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

Thank you
Pragyansh