CoreDeveloperApplication

Differences between revisions 13 and 15 (spanning 2 versions)
⇤ ← Revision 13 as of 2024-01-08 19:10:13 →
Size: 13142
Editor: vpa1977
Comment:
← Revision 15 as of 2024-01-22 19:05:29 → ⇥
Size: 15826
Editor: vpa1977
Comment:
Deletions are marked like this. Additions are marked like this.
Line 59: Line 59:
    * openjdk-21 (in progress for focal) [[https://launchpad.net/bugs/2036873|2036873]]     * openjdk-21 [[https://launchpad.net/bugs/2036873|2036873]]
Line 151: Line 151:
 * Launchpad Merge UI - it might be a good rainy day project for me to prototype something similiar to Github UI and propose it to Launchpad team.  * 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.
Line 182: Line 182:


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

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.

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)