MOTUDeveloperApplication

Differences between revisions 11 and 18 (spanning 7 versions)
Revision 11 as of 2022-06-17 09:40:48
Size: 4569
Editor: alexghiti
Comment:
Revision 18 as of 2022-09-13 12:57:56
Size: 8869
Editor: alexghiti
Comment:
Deletions are marked like this. Additions are marked like this.
Line 17: Line 17:
* It will also my team to clear our sponsorship queue. * I will help clear the sponsorship queue.
Line 23: Line 23:
I am a software engineer living in Grenoble, France, I currently work in the Foundations team for Canonical. I usually contribute to the kernel, my focus being RISC-V and when I don't, I work on some personal projects (all involve my computer of course :)). I am a software engineer living in Grenoble, France, I currently work in the Foundations team for Canonical. For a few years now, my focus is RISC-V, more specifically the kernel and when I don't work on this subject, I work on some personal projects (all involve my computer of course :)).
Line 27: Line 27:
I discovered the free software late when I entered my Engineering school in Grenoble, but I have been programming since I'm a teen, at that time my focus was more algorithmic so I did not have the need to tickle my environment.
(I really understood the need for free software in my first job when the project was to create a new high-performance processor: without a free and open-source kernel, compiler...etc, this would have been impossible.)
I discovered free software late when I entered my engineering school in Grenoble where I studied operating systems. And I began contributing to open source softwares with the kernel as I had experience in this area from my first job and I was willing to help (and have fun too).
Line 30: Line 29:
I studied operating systems and began contributing to open source software with the kernel as I had experience in this area from my first job and I was willing to help (and have fun too).

I usually had a Linux Mint distribution from the time of my cheap student laptop and then switched to Ubuntu when I installed it to some close relatives a few years ago, so I guess I have always used Ubuntu :)
I usually had a Linux Mint distribution from the time of my cheap student laptop and then switched to Ubuntu when I installed it to some close relatives a few years ago, so I guess I have always used Ubuntu.
Line 39: Line 35:
In the long term,
Line 45: Line 39:
* https://udd.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=&sponsor_search=name&sponsoree=*chopin*&sponsoree_search=name > 50 sponsored packages:
Line 47: Line 41:
OpenSSL 3: https://udd.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=&sponsor_search=name&sponsoree=*ghiti*&sponsoree_search=name
Line 49: Line 43:
* https://lists.ubuntu.com/archives/ubuntu-devel/2021-August/041589.html 2 MIRs:
Line 51: Line 45:
* https://lists.ubuntu.com/archives/ubuntu-devel/2021-October/041639.html https://bugs.launchpad.net/ubuntu/+source/libisofs/+bug/1977959
https://bugs.launchpad.net/ubuntu/+source/jigit/+bug/1978066
Line 53: Line 48:
My Debian Maintainer application, even though I since let it lapsed: > 5 SRUs:
Line 55: Line 50:
* https://lists.debian.org/debian-newmaint/2013/04/msg00005.html https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1944741
https://bugs.launchpad.net/ubuntu/+source/nezha-boot0/+bug/1965260
https://bugs.launchpad.net/ubuntu/+source/u-boot-nezha/+bug/1976594
https://bugs.launchpad.net/ubuntu/+source/flash-kernel/+bug/1978923
https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1980929

2 +1 reports:

https://www.mail-archive.com/ubuntu-devel@lists.ubuntu.com/msg10177.html
https://www.mail-archive.com/ubuntu-devel@lists.ubuntu.com/msg10425.html
Line 63: Line 67:
I don't 'work' to get known by the community, because this is my nature and also by a sentiment of lack of legitimacy which will be partly fixed by becoming a MOTU. I don't communicate enough with the community. I think being a MOTU will make me more legitimate and will improve that.
Line 65: Line 69:
I learnt a lot about the processes, but now I have to focus on the details, it often happens that I forget a bug number, that I mess a version in my PPA and ask for my sponsor to fix it. I learnt a lot about the processes, but now I have to focus on the details, it happens that I forget a bug number, that I mess a version in my PPA and ask for my sponsor to fix these.
Line 67: Line 71:
And I really need to pay more attention to all the tools that exist to help us.
Line 71: Line 76:
I want to work on the distribution fundamentals and by its nature, the RISC-V architecture brings a new kind of problem that may need such innovative solutions.
 
I want to work on the distribution fundamentals and by its nature, the RISC-V architecture may bring new kinds of problems that may need innovative solutions.
Line 76: Line 80:
First it would be the sponsoring process: it is very long, random, discouraging and time wasting. I will contribute more knowing that I have upload rights and since nobody will check my work, I'll necessarily pay more attention to details.
Line 77: Line 82:
Then I think it misses a documentation on the tools that we could use to improve our workflow.
Line 84: Line 90:
''As a sponsor, just copy the template below, fill it out and add it to this section.''
Line 86: Line 91:
* `Lukas ‘slyon’ Märdian
General feedback
================

Alex joined the Ubuntu Foundations team and thus became a collegue in November 2021. He picked up mostly on low-level RISC-V enablement work, but also helped with general distro work, e.g. doing +1 maintenance shifts, handling proposed-migration and doing merges. I haven’t been directly involved with his RISC-V focus topic, but sponsored some more generic changes for him. In total I sponsored 12 uploads for Alex, which are distributed across a sync, no-change rebuild, SRUs, MIRs, merges, bug fixes. So Alex showed to understand all those processes related to the Ubuntu archive.
I recommend to use tooling like dput-ng (+ https://git.launchpad.net/~ubuntu-server/+git/ubuntu-helpers/tree/cpaelzer/.dput.d) to catch simple issues earlier, communicating openly with the Ubuntu community on #ubuntu-devel (e.g. asking for sponsorship) and continuing to do +1 maintenance shifts, where having MOTU powers should help a lot to speed things up and give the possibility to learn more about packaging work and the archive (e.g. transition details).

I endorse his MOTU application.

Specific Experiences of working together
========================================

Please add good examples of your work together, but also cases that could have handled better.

I’ve recently worked with Alex on the libgpg-error/i386 proposed-migration (https://pad.lv/1975673), an issue wich was hard to track down as it involved fixes to the autopkgtest code-base, Multi-Arch fixes to related packages in addition to the usual debugging. Understanding all the relationships, he came up with the final Multi-Arch fix that finally resolved the issue for good.
Having my MIR hat on, I’ve also worked with Alex on MIRs related to usb-creator (https://pad.lv/1977959, https://pad.lv/1978066), a process that involves getting four new dependencies accepted into main; Alex worked through all of them and resolved upcoming issues.
On the SRU side I sponsored a long-standing nezha-boot0 change for him, which was kind of special, due to bing a full version backport. Alex was involved in the SRU team discussions to getting this exception approved.
Areas of Improvement

As Alex mentioned himself, I’d recommend putting some more attention to details when working on packages. As a sponsor I had to sometimes fix smaller issues, like adding LP bug numbers to debian/changelog or running update-maintainer on top of his diffs. We also had to re-upload nezha-boot0 due to a typo in the code, which is something that can happen to anyone, but double checking for such details should help to avoid duplicate work in the future. After mentioning issues once, Alex improved upon those for his follow-up sponsoring requests, in addition to submitting relevant patches to Debian and attaching debdiffs/git-ubuntu MPs to the LP bug reports (instead of just providing a PPA build).


* Lukasz 'sil2100' Zemczak
General feedback
================

Alex is responsible for a lot of the RISC-V effort in Ubuntu, and he’s always very thorough in the work that he is doing. Alex is a fast learner and a good hacker, but at the same time he’s not afraid to ask questions in case things are not clear. That being said, he tries to solve issues by himself as much as possible. Seeing his work so far, I’m sure he would do a good MOTU - and this would allow him to further develop his skills and later become a Core Developer.

Specific experiences of working together
========================================

I only sponsored 4 packages in total, 2 of which were livecd-rootfs related. I was fairly happy with the work he provided with those packages. One of them introduced a regression, which both me and him missed during our initial work there. But those were certain corner cases we simply didn’t take into consideration.
Areas of improvement

Only areas of improvement I can think of is being more attentive for corner cases.

I, Alexandre Ghiti, apply for MOTU status within the Ubuntu community.

Name

Alexandre Ghiti

Launchpad Page

https://launchpad.net/~alexghiti

Wiki Page

N/A

I am applying because:

* I have contributed quite a few packages now, to both Debian and Ubuntu and feel comfortable enough with the overall process.

* I sometimes worked on a package, waiting for a sponsor, and someone else uploaded it in the meantime: this is a waste of time for everyone.

* I will help clear the sponsorship queue.

* I want to get more responsibility, because the more responsible, the more I feel involved and happy to contribute.

Who I am

I am a software engineer living in Grenoble, France, I currently work in the Foundations team for Canonical. For a few years now, my focus is RISC-V, more specifically the kernel and when I don't work on this subject, I work on some personal projects (all involve my computer of course :)).

My Ubuntu story

I discovered free software late when I entered my engineering school in Grenoble where I studied operating systems. And I began contributing to open source softwares with the kernel as I had experience in this area from my first job and I was willing to help (and have fun too).

I usually had a Linux Mint distribution from the time of my cheap student laptop and then switched to Ubuntu when I installed it to some close relatives a few years ago, so I guess I have always used Ubuntu.

My involvement

My focus is on enabling the RISC-V architecture which consists in fixing RISC-V specific issues and adding packages to allow better support of existing hardware. But as part of the Foundations team, it often happens that I have to fix packages outside of the RISC-V scope.

Examples of my work / Things I'm proud of

Overall:

> 50 sponsored packages:

https://udd.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=&sponsor_search=name&sponsoree=*ghiti*&sponsoree_search=name

2 MIRs:

https://bugs.launchpad.net/ubuntu/+source/libisofs/+bug/1977959 https://bugs.launchpad.net/ubuntu/+source/jigit/+bug/1978066

> 5 SRUs:

https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1944741 https://bugs.launchpad.net/ubuntu/+source/nezha-boot0/+bug/1965260 https://bugs.launchpad.net/ubuntu/+source/u-boot-nezha/+bug/1976594 https://bugs.launchpad.net/ubuntu/+source/flash-kernel/+bug/1978923 https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1980929

2 +1 reports:

https://www.mail-archive.com/ubuntu-devel@lists.ubuntu.com/msg10177.html https://www.mail-archive.com/ubuntu-devel@lists.ubuntu.com/msg10425.html

Areas of work

Low-level packages such as u-boot, opensbi, flash-kernel...etc. But actually anything to enhance our RISC-V support.

Things I could do better

I don't communicate enough with the community. I think being a MOTU will make me more legitimate and will improve that.

I learnt a lot about the processes, but now I have to focus on the details, it happens that I forget a bug number, that I mess a version in my PPA and ask for my sponsor to fix these.

And I really need to pay more attention to all the tools that exist to help us.

Plans for the future

General

I want to work on the distribution fundamentals and by its nature, the RISC-V architecture may bring new kinds of problems that may need innovative solutions.

What I like least in Ubuntu

First it would be the sponsoring process: it is very long, random, discouraging and time wasting. I will contribute more knowing that I have upload rights and since nobody will check my work, I'll necessarily pay more attention to details.

Then I think it misses a documentation on the tools that we could use to improve our workflow.

Comments

If you'd like to comment, but are not the applicant or a sponsor, do it here. Don't forget to sign with @SIG@.


Endorsements

* `Lukas ‘slyon’ Märdian General feedback ================

Alex joined the Ubuntu Foundations team and thus became a collegue in November 2021. He picked up mostly on low-level RISC-V enablement work, but also helped with general distro work, e.g. doing +1 maintenance shifts, handling proposed-migration and doing merges. I haven’t been directly involved with his RISC-V focus topic, but sponsored some more generic changes for him. In total I sponsored 12 uploads for Alex, which are distributed across a sync, no-change rebuild, SRUs, MIRs, merges, bug fixes. So Alex showed to understand all those processes related to the Ubuntu archive. I recommend to use tooling like dput-ng (+ https://git.launchpad.net/~ubuntu-server/+git/ubuntu-helpers/tree/cpaelzer/.dput.d) to catch simple issues earlier, communicating openly with the Ubuntu community on #ubuntu-devel (e.g. asking for sponsorship) and continuing to do +1 maintenance shifts, where having MOTU powers should help a lot to speed things up and give the possibility to learn more about packaging work and the archive (e.g. transition details).

I endorse his MOTU application.

Specific Experiences of working together ========================================

Please add good examples of your work together, but also cases that could have handled better.

I’ve recently worked with Alex on the libgpg-error/i386 proposed-migration (https://pad.lv/1975673), an issue wich was hard to track down as it involved fixes to the autopkgtest code-base, Multi-Arch fixes to related packages in addition to the usual debugging. Understanding all the relationships, he came up with the final Multi-Arch fix that finally resolved the issue for good. Having my MIR hat on, I’ve also worked with Alex on MIRs related to usb-creator (https://pad.lv/1977959, https://pad.lv/1978066), a process that involves getting four new dependencies accepted into main; Alex worked through all of them and resolved upcoming issues. On the SRU side I sponsored a long-standing nezha-boot0 change for him, which was kind of special, due to bing a full version backport. Alex was involved in the SRU team discussions to getting this exception approved. Areas of Improvement

As Alex mentioned himself, I’d recommend putting some more attention to details when working on packages. As a sponsor I had to sometimes fix smaller issues, like adding LP bug numbers to debian/changelog or running update-maintainer on top of his diffs. We also had to re-upload nezha-boot0 due to a typo in the code, which is something that can happen to anyone, but double checking for such details should help to avoid duplicate work in the future. After mentioning issues once, Alex improved upon those for his follow-up sponsoring requests, in addition to submitting relevant patches to Debian and attaching debdiffs/git-ubuntu MPs to the LP bug reports (instead of just providing a PPA build).

* Lukasz 'sil2100' Zemczak General feedback ================

Alex is responsible for a lot of the RISC-V effort in Ubuntu, and he’s always very thorough in the work that he is doing. Alex is a fast learner and a good hacker, but at the same time he’s not afraid to ask questions in case things are not clear. That being said, he tries to solve issues by himself as much as possible. Seeing his work so far, I’m sure he would do a good MOTU - and this would allow him to further develop his skills and later become a Core Developer.

Specific experiences of working together ========================================

I only sponsored 4 packages in total, 2 of which were livecd-rootfs related. I was fairly happy with the work he provided with those packages. One of them introduced a regression, which both me and him missed during our initial work there. But those were certain corner cases we simply didn’t take into consideration. Areas of improvement

Only areas of improvement I can think of is being more attentive for corner cases.


TEMPLATE

== <SPONSORS NAME> ==
=== General feedback ===
## Please fill us in on your shared experience. (How many packages did you sponsor? How would you judge the quality? How would you describe the improvements? Do you trust the applicant?)

=== Specific Experiences of working together ===
''Please add good examples of your work together, but also cases that could have handled better.''
## Full list of sponsored packages can be generated here:
##  https://udd.debian.org/cgi-bin/ubuntu-sponsorships.cgi
=== Areas of Improvement ===


CategoryMOTUApplication

AlexandreGhiti/MOTUDeveloperApplication (last edited 2022-09-21 13:33:13 by ginggs)