MOTUDeveloperApplication
|
Size: 12323
Comment:
|
Size: 9694
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| ## page was renamed from SimonChopin/ContributingDeveloperApplication | |
| Line 6: | Line 5: |
| '''I, Simon Chopin, apply for MOTU status within the Ubuntu community.''' | '''I, Alexandre Ghiti, apply for MOTU status within the Ubuntu community.''' |
| Line 8: | Line 7: |
| || '''Name''' || Simon Chopin || || '''Launchpad Page''' || https://launchpad.net/~schopin || |
|| '''Name''' || Alexandre Ghiti || || '''Launchpad Page''' || https://launchpad.net/~alexghiti || |
| Line 14: | Line 13: |
| * I have taken an active role within the development community that requires to be able to communicate on all dev channels, including the ubuntu-devel@lists.ubuntu.com ML, which is moderated for non-dev members. |
* I have contributed quite a few packages now, to both Debian and Ubuntu and feel comfortable enough with the overall process. |
| Line 18: | Line 15: |
| * I'll be involved in multiple uploads throughout the archive as part of my Foundations work, dealing with transitions and toolchains updates, and would like to decrease the pressure on the sponsorship queue. | * 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. |
| Line 20: | Line 17: |
| * Being a MOTU means I can help clear the sponsorship queue, selfishly meaning Core devs have more time to look at my work ;-) |
* 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. |
| Line 25: | Line 23: |
| I am a software engineer hailing from Brittany, France, currently employed by Canonical within the Foundations team. When I'm not working on the internals of Ubuntu as part of my dayjob, you'll usually find me playing either music or videogames, both of which usually involve fiddling with my computer setup ;-). | 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 29: | Line 27: |
| My Ubuntu story is, for a big part, a Debian 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). |
| Line 31: | Line 29: |
| Ubuntu was my first successful attempt at Linux back in 2006 on an old laptop, thanks to the free CD shipping program that was running back then. I kept running a dual-boot until 2009, when I had a new laptop which couldn't run the latest Ubuntu but could run the latest Debian. I pragmatically switched to the mother distro, and over the years ended up involved in Python packaging (DPMT and PAPT teams), indirectly working for Ubuntu ;-). Ironically, my FLOSS contributions died down when I used Ubuntu again, both due to my first job after college. It was only server-side, but its extra-long version strings felt very familiar indeed! I became the resident expert on deploying our applications on our servers, putting my packaging knowledge to good use. After a few years, I switched jobs, and ended up maintaining a whole internal distribution based on Debian, as well as spearheading a grassroot movement to have technical roles in the company use Linux laptops instead of OSX, insisting on Ubuntu LTS on those. This led me to my current job at Canonical, where I'm happily greasing the internal wheels of Ubuntu so that other, more user-facing teams can deliver a good experience to all of our users, including myself and many around me who've switched to 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 33: |
| As part of the Foundations team, my area of impact includes language toolchains, bootloaders, installer, and other core components of the system. I've touched a rather wide range of packages, mostly C libraries and utilities, but my main involvements are netplan development and OpenSSL packaging, for which I'm currently driving the transition to version 3.0. Outside of my day job, I don't have a big impact at the moment, but my long-term aspirations are to work on reducing the gap between Ubuntu and Debian, and work upstream with the Debian QA team for the good of both their and our archive. |
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. |
| Line 46: | Line 38: |
| https://udd.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=&sponsor_search=name&sponsoree=*chopin*&sponsoree_search=name | |
| Line 48: | Line 39: |
| OpenSSL 3: https://lists.ubuntu.com/archives/ubuntu-devel/2021-August/041589.html https://lists.ubuntu.com/archives/ubuntu-devel/2021-October/041639.html |
> 50 sponsored packages: |
| Line 52: | Line 41: |
| My Debian Maintainer application, even though I let it lapsed: | https://udd.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=&sponsor_search=name&sponsoree=*ghiti*&sponsoree_search=name |
| Line 54: | Line 43: |
| https://lists.debian.org/debian-newmaint/2013/04/msg00005.html | 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 |
| Line 58: | Line 63: |
| As mentioned above, my work leads me to work on OpenSSL- and netplan-related matters. I also have personal interest in the Rust ecosystem and might get involved in its packaging (once we sort it out properly). |
Low-level packages such as u-boot, opensbi, flash-kernel...etc. But actually anything to enhance our RISC-V support. |
| Line 63: | Line 67: |
| Actively seek out interactions outside of the Foundations Team! Also, my uploads could be perfectible, as there is usually a detail (such as a bug number) missing. | 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. |
| Line 68: | Line 76: |
| I of course intend to become Core dev myself, both for my coworkers' sake and mine. | 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 72: | Line 80: |
| There is no clear-cut way to contribute to an existing package. Some are maintained in Launchpad in a git repository somewhere, which isn't obvious to find, some are directly using the archive as "VCS", and expect a debdiff directly on the launchpad bug, but you'll find a git repository for some of those packages still, via the git-ubuntu package, making things that much harder to grasp. | 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 74: | Line 82: |
| I could contrast this with many other distros, but even Debian seems clearer to me, as all "landing pages" for a given package are interlinked and most of them have a link to whatever VCS is used to maintain the package. | Then I think it misses a documentation on the tools that we could use to improve our workflow. |
| Line 82: | Line 90: |
| ''As a sponsor, just copy the template below, fill it out and add it to this section.'' | |
| Line 84: | Line 91: |
| == Lukas 'slyon' Märdian == | `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. == Graham Inggs == |
| Line 86: | Line 128: |
| I have been mentoring Simon after he joined the Ubuntu Foundations team in early July 2021. Due to his prior Debian experience Simon didn't need a lot of mentoring wrt. distro work, but was able to cooperate with the developer community on #ubuntu-devel in a very transparent and engaged way from the very start! He showed a great learning ability too as he got into the netplan codebase in no time, cranking out high quality pull requests, touching core parts of the application while keeping backwards compatibility, testing and code style in good shape. Besides `netplan.io` SRUs and a `lksctp-tools` sync, I sponsored the `s390-tools[-signed]` package for Simon in "main", which has some special bits to it (wrt. to package signing on Launchpad) that he was easily able to grasp. I also synced `git-remote-hg` (to pull in Debian's autopkgtest fix that Simon spotted) and `racket` into "universe" for Simon to support him during his first "+1 Maintenance" session and reviewed his `haveged` merge that I was able to upload without any nitpicking. He is always attentive and curious about new things that he reads about in some git commits and does not hesitate to ask any questions to the relevant people if anything is unclear. Simon has collected lots of experience preparing the OpenSSL 3 transition and could put his MOTU powers to good use in helping to clean up the universe outfall after this transition lands. In all of his work he has always focused on delivering high quality results. I trust in his skills and decision making in the best interest of the Ubuntu community. The MOTU membership should only be a first step on Simon path in becoming a Core-Dev and joining additional teams in the future, as he absolutely has the potential to do so. I fully endorse his MOTU application. |
I've worked with Alex for just over one year, and in the past nine months I've sponsored 17 uploads for him. The quality has been good and when minor changes were required they were done quickly. I trust that Alex has a good understanding of our procedures to become a MOTU a now, which will make him more effective at +1 maintenance, and allow him to gain the experience required to become a Core Dev in future. |
| Line 93: | Line 131: |
| ''Please add good examples of your work together, but also cases that could have handled better.'' | * Many of the uploads I sponsored were fixes found during +1 maintenance, one was https://launchpad.net/ubuntu/+source/gcc-mingw-w64/24.4ubuntu1 which was solved as a result of the multi-arch fix for autopkgtest mentioned above |
| Line 95: | Line 133: |
| Besides supporting Simon's daily distro work (as described above) I've primarily worked with him as part of the upstream netplan project. Since joining Canonical he pushed 13 PRs to Github (https://github.com/canonical/netplan/pulls?q=author%3Aschopin-pro) all of which have been of very high quality and great form (i.e. git commit structure & description). He always reacted quickly and open minded to any comments made during review and resolved any issues to everybody's satisfaction. He also jumped in to do upstream netplan reviews for other community members and for myself and has been an excellent sparring partner for me doing so. | * https://launchpad.net/ubuntu/+source/u-boot-nezha/2022.04+git20220405.7446a472-0ubuntu0.1 was an SRU to jammy |
| Line 97: | Line 135: |
| * https://launchpad.net/ubuntu/+source/netdata/1.34.1-1 was a sync from Debian to drop an Ubuntu delta | |
| Line 98: | Line 137: |
| There are always new things to learn in Ubuntu. Simon could be creating MIR bugs, do more SRU work (also some special cases, like netplan backports), creating NEW packages and getting packages removed from the archive where needed. In continuing his "+1 Maintenance" engagement he will inevitably come across such cases and grow his abilities while working through them. == Stefano Rivera == === General feedback === I sponsored 37 uploads for Simon in Debian in 2011-2014. We co-maintained beets and he packaged some of the supporting python libraries. There was, of course, a learning process, but by the end of that time I would have felt happy to endorse Simon for uploading rights in Debian. Hopefully we'll see him back there again :) I enjoyed working with him, and think he'll make a great MOTU & core-dev. === Specific Experiences of working together === || source || version || modified || || rgain || 1.0.1-1 || 2011-12-01 13:33:53.377208+00|| || audioread || 0.2-1 || 2011-12-25 13:17:14.703129+00|| || pyacoustid || 0.3-1 || 2011-12-25 13:18:30.182192+00|| || musicbrainzngs || 0.1-1 || 2012-01-20 21:33:23.884628+00|| || beets || 1.0~b12-1 || 2012-01-21 23:32:11.272977+00|| || audioread || 0.3-1 || 2012-02-03 19:32:14.548309+00|| || pylast || 0.5.11-1 || 2012-02-03 22:05:04.967514+00|| || pyacoustid || 0.4-1 || 2012-02-19 22:20:30.732959+00|| || beets || 1.0~b13-1 || 2012-03-21 11:47:11.839511+00|| || pyacoustid || 0.6-1 || 2012-04-05 16:17:51.31752+00|| || musicbrainzngs || 0.2-1 || 2012-04-08 21:05:01.911374+00|| || audioread || 0.5-1 || 2012-04-08 21:32:21.650541+00|| || pytest || 2.2.3-1 || 2012-04-11 15:47:31.014182+00|| || pytest || 2.2.3-2 || 2012-04-13 18:48:00.153076+00|| || pytest || 2.2.3-3 || 2012-04-17 11:34:57.936529+00|| || pyacoustid || 0.7-1 || 2012-06-01 12:06:51.071777+00|| || audioread || 0.6-1 || 2012-06-01 12:47:09.705902+00|| || pytest || 2.2.4-1 || 2012-06-03 01:19:52.348568+00|| || beets || 1.0~b14-2 || 2012-06-04 21:17:22.090818+00|| || execnet || 1.0.9-0.1 || 2012-06-05 17:03:29.305994+00|| || pytest-xdist || 1.8-0.1 || 2012-06-05 17:06:24.942807+00|| || pytest || 2.2.4-2 || 2012-06-24 20:53:31.205968+00|| || audioread || 1.0.1-1 || 2013-05-14 21:18:01.648002+00|| || pyacoustid || 1.0.0-1 || 2013-05-14 21:22:54.165539+00|| || rgain || 1.2-1 || 2013-05-14 21:23:18.220395+00|| || musicbrainzngs || 0.4-1 || 2013-05-26 21:23:25.153856+00|| || mutagen || 1.21-1 || 2013-07-16 21:48:45.025052+00|| || beets || 1.2.1-1 || 2013-07-22 15:03:09.630609+00|| || beets || 1.3.1-1 || 2013-11-30 09:18:55.315917+00|| || audioread || 1.0.3-1 || 2014-09-29 07:48:31.46463+00|| || pyacoustid || 1.1.0-1 || 2014-09-30 16:49:52.25351+00|| || musicbrainzngs || 0.5-1 || 2014-09-30 18:08:04.087775+00|| || responses || 0.2.2-1 || 2014-10-12 21:24:05.166866+00|| || pylast || 1.0.0-1 || 2014-10-14 03:36:06.89226+00|| || responses || 0.3.0-1 || 2014-10-14 03:36:15.460555+00|| || rgain || 1.3.3-1 || 2014-10-16 03:56:42.579458+00|| || beets || 1.3.8+dfsg-1 || 2014-10-23 22:52:03.602286+00|| === Areas of Improvement === As this was many years ago, it's hard to recall. Nothing comes to mind. |
None at the moment |
| Line 165: | Line 152: |
| Line 167: | Line 153: |
| ## Uncomment the one that applies for you and please remove the others. ## |
I, Alexandre Ghiti, apply for MOTU status within the Ubuntu community.
Name |
Alexandre Ghiti |
Launchpad Page |
|
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:
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.
Graham Inggs
General feedback
I've worked with Alex for just over one year, and in the past nine months I've sponsored 17 uploads for him. The quality has been good and when minor changes were required they were done quickly. I trust that Alex has a good understanding of our procedures to become a MOTU a now, which will make him more effective at +1 maintenance, and allow him to gain the experience required to become a Core Dev in future.
Specific Experiences of working together
* Many of the uploads I sponsored were fixes found during +1 maintenance, one was https://launchpad.net/ubuntu/+source/gcc-mingw-w64/24.4ubuntu1 which was solved as a result of the multi-arch fix for autopkgtest mentioned above
* https://launchpad.net/ubuntu/+source/u-boot-nezha/2022.04+git20220405.7446a472-0ubuntu0.1 was an SRU to jammy
* https://launchpad.net/ubuntu/+source/netdata/1.34.1-1 was a sync from Debian to drop an Ubuntu delta
Areas of Improvement
None at the moment
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 ===
AlexandreGhiti/MOTUDeveloperApplication (last edited 2022-09-21 13:33:13 by ginggs)