I, Tiago Stürmer Daitx, apply for core-dev.
Name |
Tiago Stürmer Daitx |
Launchpad Page |
|
Wiki Page |
Who I am
I have a B.Sc. in Physics, where I ended up writing software in C and Fortran for research. By gradutation I was working on web-development and on the infrastructure required to get that ship sailing - that involved setting up and maintaining servers and their various services: databases, http servers, firewalls, etc. I went from cgi-bin written in C to PHP and after a few years I parashutted into the Java land. I stepped outside web-development for a while to work on satellite image using IDL, Envy, C, Java, and a mixed amalgam of all these languages. From there I went to work on Java ME frontends and Jave EE backends. All the way I was always somehow involved in infrastructure setup, maintenance, and devops. During all this time the infrastrucure has always been Linux based, altought the distros varied: Slackware, Debian, Conectiva, Mandrake, SuSE, Ubuntu, RHEL, Fedora, Archlinux, and many others.
In 2008 I landed a job in IBM's Linux Technology Center in Brazil, where I worked in the infrastructure team supporting and maintaining internal tools for various other teams. The work involved Bugzilla, Testopia, and internal build tools and CI. I eventually moved to the toolchain team where I worked mostly on GDB and OpenJDK support for PPC64LE as well as kickstarting a few packages during Debian's PPC64LE port. Since 2015 I have been working on the foundations team in Canonical, were most of my work was concentrated on OpenJDK package maintenance and security updates - I also help on various other issues (FTBFS, SRUs, merges, etc) that make our day-to-day.
My Ubuntu story
I was an eventual Ubuntu user from Hoary to Gutsy, moving sometimes to Debian or other distros as required to get the best support for the hardware at the time. When I started working for IBM's Linux Technology Center in 2008 I got back to Ubuntu, following it from Hardy to Maverick (I survived a few bad distro updates there), but Unity led me away again to other distros - at that time this was due mostly to limited hardware resources, and I needed all the free RAM I could get. Nowadays the Devel version is my mainly driver - although I do deviate from the standard DE and rely heavily on i3wm.
My involvement
As a Foundations team member I am a generalist. I worked on FTBFS fixes, merges, triaging, helped on GCC5 transition, contributed fixes to both Debian and upstream, etc. My main focus is OpenJDK and java related package maintenance.
Examples of my work / Things I'm proud of
The Ubuntu Sponsorship miner has a list of packages that I have worked on and Launchpad has a list of my uploads.
Sometimes I find that the hardest part is figuring out good and expressive test cases for SRUs. I aim to have a clear statement of the expected stated of the system to be used for testing, the explicit steps, and the "expected versus actual" output in order make sure the issue is reproducible and verifiable.
The Xenial and Bionic SRUs for 1667512 and 1791959: in the initramfs-tools package took me some time to get the test cases sorted out, specially on the former bug as it involved quite a few steps and I tried to make them work for 2 different distros. On the later, while I usually dislike leaving out the actual commands to run, I went for "Setup a nfs server and export a directory with write permissions for the client" as step one since the particulars of this setup would add too many elements (eg. paths and ips) to the test case while decreasing its legibility. I resorted to a merge proposal and included both fixes in a single SRU. The Bionic fix had a small error (it was checking for the Xenial package version) that went undetected during review but showed up during my SRU verification. I quickly issued another fix on top to get it done. This whole process was a good experience to review and talk to other devs and my sponsors to get the fixes in place.
The OpenJDK-10 and OpenJDK-11 migrations were a good experience on how work with SRU and FF exceptions (1791716 and 1760920), as coordinating fixes that included merges (eg. 1794135), dropping deltas for syncs (eg. 1794129), as well as making sure packages were being uploaded in the right order when some bootstrapping was needed. This involved some last minute patches (eg. 1796985 for clojure1.8) to migrate the openjdk-11 package out of proposed. Although it was an interesting and exciting exercise - specially now that it is done - it was a close call that I do not intent to repeat.
The ca-certificates-java SRU in 1771363 (and also 1739631) was a nice experience on the different ways team use SRU when fixing more than one bug. 1739631 came from Debian but only fixed the issue for a clean install: users that had already been affected were on the woods, so the extra fix from 1771363 was required. The original issue had been fixed in Cosmic and my new fix landed there just fine, but Bionic still need both SRUs. Originally 1770553 was created to deal with this SRU after quick discussions and deciding for a meta-bug SRU - similar to what is done by the kernel team. Later on this generated some disagreement between a few core devs on how to best proceed with the SRU: do separated SRU for each bug or use the last one as a meta-SRU bug. I ended up simplifying 1770553 and improved the descriptions and test cases for both 1771363 and 1739631, so each bug had separated test cases for their own scenarios. This solution was readly accepted and the SRU was sponsored and later on approved.
libcommons-lang3-java required a 2-step upload (similar to bootstrapping) to fix 1788735, this required some testing and coordination with my sponsor to get it done.
The ceph Bionic SRU in 1766998 was pretty easy but it was not clear how to actually test it since getting ceph setup and working was not exactly trivial, at the end I went with the tests from the package and the fact that no regressions were introduced.
- I frequently use error.ubuntu.com tracker to check for regressions after updates in packages I worked on and I also got apport scripts for the openjdk packages which helped me get additional information from the reports.
Other:
Upstreamed xrender fix from openjdk-7 package to Icedtea - PR2571, which was also backported to 6 in PR2662
Areas of work
I have worked mainly within the Foundations team to fix FTBFS, provide merges, help maintain and update several packages in universe and main. I did work on packages from other teams but usually those only required some light coordination with these other team members to be sure I was not stepping on someone else's toes.
Due to the way the openjdk security updates are done I make sure the patches apply correctly, backport whatever is needed, test the resulting package, and then upload it to the security team for additional checks and the eventual release. This has worked quite well over time with very few releases requiring an extra upload to fix problems. The same patches are also applied and uploaded to Debian through sponsoring.
I also work from time to time with the Debian Java packaging team providing bug reports and fixes - this has become more common with the openjdk-9, -10, and -11 migrations as each onet broke quite a lot of other packages. This has worked quite well and they have been very helpful on getting all this going.
Things I could do better
- I need to work a bit smarter to separate the things that need careful work from the ones that need fast feedback. I tend play on the careful side and to spend a lot of time trying to get things a bit too perfect, even when I could benefit from a faster roundtrip for reviews or getting other's opinions. While there's the good side of saving a lot of work to whomever is reviewing/sponsoring my work there are some situations where I could save time by getting stuff out earlier.
- Need to dedicate more time for getting the gist of working with git for packaging and merging.
- Increase the time I dedicate to triaging bugs. The backlog of bugs in some of the packages I work on have been getting bigger.
Plans for the future
General
- Package, integrate new features, release security updates, SRU important stuff.
- Develop good relationship with the upstream projects and Debian.
- Actively participate on bug triaging, sponsoring, and try my best to share my experience.
- Increase my use of git for the packages I work with so I can leave a breadcrumb for others (or my future self) to follow.
- Participate in the new +1 Vanguard program
- Get even more involved with Ubuntu and gather enough knowledge/experience to join the DMB
What I like least in Ubuntu
- I used to dislike merges because of the many different ways to track packages (LP projects, bzr, git, debian, upstream) together with the combination of releases and their SRUs - it was even worse when packages had no VCS at all. This made it harder to track down changes and deal with merges. Still, this is getting a lot better nowadays: the git workflow from Ubuntu Server has improved this by a lot. The migration from bzr to git is also a very good thing.
- The lack of or - worse - misleading documentation on parts of Ubuntu development has made it harder to gather the right knowledge to become a better Ubuntu dev/maintainer. Sometimes the docs are just old, sometimes teams do things differently - but the fact is not stated and it is hard to pick which one to use/rely on -, sometimes there's more than one way to do it... I only got to know some of the answers for that by talking to other devs or hitting a wall and being told to do it differently. Still, there has been improvements (as in the git workflow above as adoption increases) and the discussions about how/when to approve/reject SRUs that led to better documentation in the wiki.
- SRU requests without a proper testcase. The testcase not only should allow for reproduction of the bug but it should also be verifiable so some can check that the fix is indeed doing what is expected of it.
- Lack of DEP3 headers in patches is a pain. The changelog entries tend to be too sort and might only mention the patch in an abstract way - if there's any mentioning at all. Without the DEP3 it might be very hard to link a patch to a bug entry and figure out why and when a patch was included.
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
As a sponsor, just copy the template below, fill it out and add it to this section.
Steve Langasek
General feedback
Tiago has been contributing to Ubuntu for several years now, over the course of which I have sponsored some 13 uploads for him, including a few SRUs. He has uploaded a number of fixes as part of +1 maintenance work to a range of packages, amply demonstrating his competence in fixing issues in C, Java, and Debian packaging. I think it's well past time that he be granted core-dev status, as none of my recent sponsorships required any changes.
Mathieu Trudel-Lapierre (cyphermox)
General feedback
I've reviewed a few uploads from Tiago and have found all to be high quality. There were some cases where I had questions, in which case Tiago was quick to respond and clarify things. He does not hesitate to ask for feedback or guidance when necessary. I'm absolutely convinced that he would be an asset to the core-dev community.
Specific Experiences of working together
All uploads in the link above are a good example of the work I have sponsored for Tiago. Furthermore, we've collaborated on (agile dev pair programming) on https://github.com/lcp/mokutil/commit/4efbb0e65703e94e3b1f48006ba7511dc101c409 (upstream integration and interaction for UEFI support).
Areas of Improvement
The only thing I could say is that I would like to see Tiago lead more, be a little more visible in the community; but I am aware that my vision is possibly due to the main focus (read: maintaining Java) of his work, which has little overlap with mine.
Steve Beattie
General Feedback
I have worked with Tiago for a few years now, sponsoring his security updates for the OpenJDK packages (these occur quarterly). He has performed careful, concientious work while maintaining these packages, for which the packaging and build system are complex. He is quick to respond when issues do arise, and takes feedback well. Tiago would make an excellent addition to the core-dev community.
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: ## http://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi? === Areas of Improvement ===