CoreDeveloperApplication

I, Vladimir Petko, apply for core-dev.

Name

Vladimir Petko

Launchpad Page

https://launchpad.net/~vpa1977

Wiki Page

https://wiki.ubuntu.com/vpa1977

I am applying because:

  • I'd like to eliminate delays in getting my work sponsored.
  • I'd like to reduce the burden on my sponsors.
  • Be able support core toolchains initiative - introduce a set of core toolchain packages (e.g. build tools such as ant, maven) into main
  • Help with the Patch Pilot program
  • Support team efforts such as proposed-migration and +1 maintenance.
  • Assist in toolchain migrations (e.g. default Java 21)

Who I am

A software developer from Hamilton, New Zealand currently employed by Canonical within the Foundations team.

Prior to joining Canonical I have worked for First Watch (NZ cybersecurity startup), Gallagher (Physical Access Control), OpenWay (Credit card processing), Alcatel-Lucent (Convergent Rating Engine), TopsBI (Life insurance project) and Togethersoft (UML modelling tool).

I hold a specialist diploma in Computer Science from St. Petersburg State Technical University and MSc from University of Waikato.

When I am not in front of the computer I enjoy spending time mountain biking or hiking.

My Ubuntu story

I have started using Ubuntu during the studies in University of Waikato (2011-2015) - I had lucid and later precise installed. It was used as a development environment for the assignments and research.

At Gallagher we have used Ubuntu as a development environment for the T20 reader and eventually switched to it for the controller development. At First Watch we have used Jammy as a host development environment.

My involvement

As a member of the toolchains squad my primary focus is Java and Java packages, though as part of normal Foundations work I am exposed to a wider range of packages, e.g. my first task was fixing cryptsetup autopackage test.

Examples of my work / Things I'm proud of

Ubuntu Contributions:

Debian Contributions:

Upstream Contributions

Areas of work

  • Provide fixes for openjdk-11..22 (doko), triaging launchpad bugs, report (and if possible ) fix issues upstream.
  • Provide bug reports and fixes for the Debian Java Team.
  • Prepare OpenJDK Security Releases with Security Team.
  • Participate in +1 maintenance and proposed-migrations.

Things I could do better

  • Better attention to detail and more use of automation to avoid producing irrecoverable typos in my work.
  • Improve communication skills/get to know more people in the community.

  • Improve my knowledge of Java hotspot internals - we are getting a few platform-specific issues such as JDK-8320278

Plans for the future

General

  • Finish clean up of openjdk-* lintian warnings.
  • Re-enable openjdk-* autopkgtests.
  • Complete libheif MIR (probably this will require creating our set of the test material for AOM).
  • Perform Java 21 migration.
  • Help to define core Java package set to improve developer experience.

What I like least in Ubuntu

  • Unmaintained packages - when investigating Java 21 FTBFSes, I have encountered a number of packages that are well behind upstream releases (e.g. weka), or fail to build for a very long time, e.g. android-platform-external-doclava. Probably core Java package effort will allow to ensure that important packages get updated in a timely manner.

  • Launchpad Merge UI - it might be a good rainy day project for me to prototype something similar to Github UI and propose it to Launchpad team.

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.

Michael Hudson-Doyle

General feedback

I have worked with Vladimir since the day he joined Canonical and have always found him to be a thoughtful and thorough contributor. He is clearly an expert on Java but I have been impressed with his willingness and ability to dig into unrelated random distro issues as well.

I am confident he has the ability to know when to stop and ask for further review of a topic and also that he will be a good reviewer and sponsor for the next round of trainee distro developers and wholeheartedly endorse this application.

Specific Experiences of working together

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

I have sponsored a few fixes that came out of +1 maintenance:

I also sponsored an openjdk-8 merge.

In all these changes, Vladimir came to the review step with a well thought out and well targeted solution that required very little review, honestly. The only detail that required tweaking were some details in which changelog entries to preserve doing merges.

Areas of Improvement

I'm not sure Vladimir has worked with a big multi-stage transition yet but he has handled Java upgrades well (much better than we have been handling them historically!) so I'm sure he can figure it all out / ask for help when appropriate.

Bryce Harrington

General feedback

I've found Vladimir easy to work with, both in having solid work and in welcoming review feedback. He's been proactive at seeking out packaging problems to tackle, and soliciting input on work items where task definitions are ambiguous, while being congenial and efficient. I've a sense he'd be a big help with Patch Pilot, language transitions, and +1 maintenance.

Specific Experiences of working together

Where I've worked most closely with Vladimir is actually on a customer project that relies on the Java stack including jtreg. The customer has had a number of packaging questions over the course of the contract that have sometimes been a bit involved to get answered. Vladimir joined the effort a few months ago, and not only addressed all of the questions, but also noted and resolved a past workaround we'd applied for them that he recognized as no longer required; this is allowing the customer to shift more fully to the ESM product. It's been a relief to have his demonstrated versatility as a packaging expert for the effort.

Beyond this, I recall reviewing some his work via patch pilot, although I don't recall exact packages or results. My recollection is that they were straightforward and the work done properly.

One package I do remember in detail was clamav, which Vladimir worked on last summer via his participation in +1 maintenance to resolve a FTBFS issue on armhf that was proving to be a bit of a stumper. Vladimir identified the issue was due to a memory management flaw, and implemented the C code to fix the memory alignment on the armhf architecture. He took the additional steps of seeking out collaboration not only with me (since I'd done the clamav merge that unearthed the bug), but also with Cisco (ClamAV's upstream) to review his change and to raise the need for an official fix to their developers. I think he also collaborated with other Ubuntu developers to ensure the service management and other issues were investigated and resolved. This experience gave me a strong impression of the quality and thoroughness of his packaging work.

Areas of Improvement

As mentioned, the experiences I've had with Vladimir have all gone well so it's hard to think of areas where to improve. The one thing I'd suggest (which I suggest to pretty much everyone) is when writing changelog entries try to provide a sentence or two about the nature/cause of the problem and/or the approach taken to achieve the fix. Sometimes this can be useful to users installing the package, but where it's really helpful is for our future packagers needing to figure something out about our changes.

Simon Quigley

General feedback

I have sponsored five packages for Vladimir: https://udd.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=Simon+Quigley&sponsor_search=name&sponsoree=Vladimir+Petko&sponsoree_search=name

I do not have a wide range of interactions with Vladimir, that being said, I see vpa1977 in #ubuntu-devel often, asking questions and solving problems. After re-reviewing the uploads, I found them to be sane, and not much was required from Vladimir, unless we did the coordination on IRC. I would echo others' comments that an update of some kind summarizing the discussion (if held elsewhere) would be beneficial.

My interactions with Vladimir do not justify a fully-qualified endorsement. That being said, I think it would be helpful to unblock vpa1977 in their work, given they work productively as a project member.

Daniel Bungert

General feedback

I would like to start by echoing Bryce's sentiment about proactivity. Vladimir has been proactive about seeking out feedback and improving his knowledge about packaging improvements.

I appreciate the consistency that Vladimir is showing with PPA builds available and ready before I'm coming across the sponsorship request. I know before I click the bug that Vladmir will have commented with links to PPAs showing passing results. The nature of the Java work that Vladimir is doing is that these packages tend to not be just a quick sbuild.

I will also echo Michael's sentiment that I trust Vladimir to stop and ask questions about things that he is unsure about.

Specific Experiences of working together

Sponsored uploads

Generally I'm interacting with Vladmir as part of sponsored work. Vladmir has built for himself a good formula that makes approaching the sponsored change as easy as possible - especially appreciated on packages that are a bit more complex such as the Java ones that he is generally looking at. The zict delta is an example of an upload where there really was no feedback necessary, simply review and upload.

Areas of Improvement

Keeping a delta small is something of an art, yet helpful in the future maintenance of the package. I think there is some room for improvement here, but I consider this to be a minor issue.

Steve Langasek

I was frustrated when Vladimir initially applied only for PPU instead of full core-dev because I had sponsored his work and already seen him to be skilled, diligent, and appropriately cautious in his work. He told me he had not applied directly for core-dev because he didn't feel he was ready to be trusted with this responsibility.

Which shows that Vladimir in his own self-assessment about whether he should make changes without first checking with a more experienced developer is already more conservative than the DMB will ever be.

He should therefore be given full core-dev status immediately to remove unnecessary barriers to his valuable work contributing to Ubuntu.

Graham Inggs

General feedback

I've sponsored 16 uploads/syncs for Vladimir. The quality has been excellent, and the comments in the merge requests have been thorough, with no need for me to ask questions. This was extremely helpful because of the difference in our timezones. I've often seen Vladimir asking questions, and feel he could be trusted with being a core developer, right now.

Specific Experiences of working together

One of the first uploads I sponsored for Vladimir was openjdk-20. It was a bit of a monster, but the detail in the changelogs and the linked bugs made the review easier. Most of the packages I have sponsored recently have been syncs, e.g. python-memcache, where Vladimir's work has been submitted to, and included in Debian.

Areas of Improvement

I'm struggling to think of areas of improvement. I don't think Vladimir has handled a library transition, but I feel this can be learned "on the job".

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 ===

vpa1977/CoreDeveloperApplication (last edited 2024-02-19 11:14:46 by ginggs)