I, Simon Quigley, apply to be a Qt 5 Uploader in the Ubuntu project.


Simon Quigley

Launchpad Page


Wiki Page


Who I am

I'm a 15 year old living in Wisconsin, USA. I have had a passion for computers ever since I was 9, starting out by learning some basic HTML on a Windows XP machine, growing my knowledge and passion from there.

My Ubuntu story

I installed Ubuntu in February of 2015 after breaking my Windows 7 install, and was instantly attracted to the development side of the project. I wanted to work with others to develop software, which was always something I wished I could do but didn't have any interested friends. But, after reading the Ubuntu Packaging Guide, I was stuck, some steps didn't work, and that discouraged me. So I gave up.

I then joined a Lubuntu IRC channel that July after finding out Lubuntu ran better on my computer. I joined that community, started working on other projects within Ubuntu such as the Ubuntu Weekly Newsletter, and I worked to get Ubuntu Membership on February 4th, 2016.

From then on, I expanded my contributions, becoming the Lubuntu Release Manager, helping run the Ubuntu Weekly Newsletter, and a few other contributions listed on my main page. I also became a Master of the Universe on August 28, 2017. I continue to do various tasks within the community as a contributor outside of my development work.

Examples of my work / Things I'm proud of

  • I directed (and did most of the work for) the Qt 5.9.3 transition and am doing the same for the 5.9.4 transition; both with little to no help from others.

Areas of work

  • I work on the Debian Qt Team to ensure that the Qt packages stay up-to-date and in a healthy state, and have worked with them to complete the Qt 5.7.1 and 5.9.1 transitions, and am now working with them to complete the 5.10.1 transition. As soon as I get my key signed (which will likely be at LFNW 2018), I plan on applying to be a Debian Maintainer so I can have upload access to these packages in Debian.
  • I collaborate with the Lubuntu (Next) Team, the Kubuntu Team, and the UBPorts Team to ensure that the releases of Qt are high-quality and satisfactory, and where there are issues, I promptly work to resolve them.

In the Bionic Beaver, the packages that I do not have upload access to are the following:

  • qtbase-opensource-src
  • qtsvg-opensource-src
  • qttranslations-opensource-src
  • qtchooser

So while this application is for upload access to the qt5 packageset, in reality, it could be considered just adding those four packages to the list of packages I can upload. The reason why I would like upload access to these packages is it would eliminate the burden that my sponsors have when a Qt transition needs to be done; I typically prepare the transition myself in Bileto, do no-change rebuilds which are apparent, test installability, etc. and then once I am ready to land the transition, I have to request that one of my sponsors push the button in Bileto which runs copy-package to devel-proposed (and puts their name in devel-changes when I am the one who did the work (and thus I am to blame should anything go wrong)). It would also come in handy should I need to prepare and upload fixes for any critical regressions (should they happen) or fixes to go to stable releases via the SRU process. Here are the packages in previous releases that I do not have upload access to:


  • qtbase-opensource-src
  • qtchooser
  • qtsvg-opensource-src
  • qttranslations-opensource-src


  • qtbase-opensource-src
  • qtchooser
  • qtdeclarative-opensource-src
  • qtfeedback-opensource-src
  • qtgraphicaleffects-opensource-src
  • qtlocation-opensource-src
  • qtmultimedia-opensource-src
  • qtpim-opensource-src
  • qtquickcontrols-opensource-src
  • qtsvg-opensource-src
  • qttranslations-opensource-src
  • qtwebkit-opensource-src
  • qtxmlpatterns-opensource-src


  • pyqt5
  • qt3d-opensource-src
  • qtbase-opensource-src
  • qtchooser
  • qtdeclarative-opensource-src
  • qtfeedback-opensource-src
  • qtgraphicaleffects-opensource-src
  • qtlocation-opensource-src
  • qtmultimedia-opensource-src
  • qtpim-opensource-src
  • qtscript-opensource-src
  • qtsensors-opensource-src
  • qtserialport-opensource-src
  • qtsvg-opensource-src
  • qttools-opensource-src
  • qtwebkit-opensource-src
  • qtx11extras-opensource-src
  • qtxmlpatterns-opensource-src

Here are the uploads I have had to get sponsored where I would not be able to upload otherwise:








August 5, 2017


diff from 5.9.1+dfsg-5ubuntu1 (in Ubuntu) to 5.9.1+dfsg-5ubuntu2



October 31, 2017

Dmitry Shachnev

diff from 5.9.1+dfsg-10ubuntu2 to 5.9.2+dfsg-4ubuntu1



November 30, 2017

LocutusOfBorg (via Bileto)

diff from 5.9.2+dfsg-4ubuntu6 (in Ubuntu) to 5.9.3+dfsg-0ubuntu1



November 30, 2017

LocutusOfBorg (via Bileto)

diff from 5.9.2-3 (in Debian) to 5.9.3-0ubuntu1



December 13, 2017

unsure (via Bileto)

diff from 5.9.2-1 (in Debian) to 5.9.3-0ubuntu1



February 27, 2018

Dmitry Shachnev

diff from 5.9.3+dfsg-0ubuntu4 (in Ubuntu) to 5.9.4+dfsg-0ubuntu3



February 27, 2018

Dmitry Shachnev

diff from 5.9.3-0ubuntu1 (in Ubuntu) to 5.9.4-0ubuntu1



February 27, 2018

Dmitry Shachnev

diff from 5.9.3-0ubuntu1 (in Ubuntu) to 5.9.4-0ubuntu1

While this list may seem small, it does not take into account the work required for the rest of the transition where I already have upload access, and reverse dependencies where I sometimes have to make minor adjustments following changes in the Qt packages. It also does not take into account the 5.9.4 transition which is almost ready to land at the time of writing.

Please note that some of these uploads show that I have uploaded them myself, but this is not the case, as they were likely landed via Bileto.

When looking at the diffs of uploads I have in the Ubuntu archive, there's a few things to keep in mind; the process sometimes can be special, and outlined below for your convenience.

The main workflow I go through doing a new upstream release for a Qt 5 package in Ubuntu is the following:

  1. Clone the source from Salsa and check out the ubuntu+1 branch if there is one (in the future this should probably change to ubuntu/$RELEASE but this is what Timo used when he did the Qt transitions so I've stuck with it), then merge changes (if any) from master. This sometimes includes adjusting the delta to accommodate for changes made in Debian.

  2. Start a new changelog entry for the new upstream release, e.g. 5.9.4-0ubuntu1. Commit this.
  3. Bump build dependencies to the new upstream version, taking care that only the build dependencies were bumped. Commit this as well.
  4. Prepare for the build by scanning the upstream changes made:
    1. Are there any function definitions which have been added or removed? (Whether or not to expect symbol changes.)
    2. Has the copyright changed for any of the files? Is this a global change or a change made only to a few files?
    3. Take a look at the upstream bugs; is there anything in Launchpad that corresponds to any one of these bugs, and can I close it in the changelog?
  5. Run it through sbuild:
    1. If there have been changes made upstream that are incompatible with changes made by a patch, sbuild will point this out, and I will refresh the patch.
    2. Are the build dependencies satisfiable? (Do I need to stop what I'm doing and work on a forgotten package?)
    3. Does the build finish correctly? If it doesn't, why? (And fix it if it fails!)
    4. During the pedantic Lintian checks I have enabled by default in my .sbuildrc, is there anything that I need to fix?
    5. If there's an autopkgtest, it will run by default (I have also defined this in my config); does it pass? If it doesn't, is the fail expected? (Did it happen before?) Fix it if it's broken (if possible).
    6. If I need to update symbols, I follow the usual process outlined by the Debian Qt/KDE Team.

  6. Once everything is satisfactory, unless there are specific bugs that need to be fixed, dch -r, git add debian/changelog, debcommit, git tag ubuntu/5.9.4-0ubuntu1 (for example).

  7. Push to Salsa and the Bileto PPA.

I pay special attention to packages like qtwebengine-opensource-src because that typically takes 5+ hours to build in Launchpad and the turnaround time for that is not smooth, so should anything go wrong, I need to catch it locally first.

There's also a special bootstrapping dance that needs to be done when the qtbase and/or qtdeclarative virtual ABI packages are bumped. In qtbase's debian/README.source, I go through the list of packages in the specified order, I do the above dance with one exception; I disable the docs from building, because there is a peculiar dependency loop. Once those packages are successfully bootstrapped, I upload versions which revert the disabling of the docs packages. This process would be a lot less tedious if I could enable build profiles in PPAs, because the nodoc build profile builds without the doc packages.

One other noteworthy piece is that I have driven the creation of the #ubuntu-qt IRC channel (which is bridged to Telegram at @ubuntuqt). This has allowed me to collaborate with other teams within Ubuntu such as the Kubuntu Team and the UBPorts Team directly on Qt, and make sure that there is one central place to discuss any issues these teams have come across while using Qt. This has also allowed me to keep informed parties up-to-date on Qt transition progress, and to allow others the opportunity to jump in and help with the Qt transitions if they wish.

Plans for the future

I plan on continuing with 5.9 LTS in Ubuntu 18.04 and providing maintenance for that throughout the span of the support period. The plan for 18.10 then is to keep an extremely small delta with Debian and do the majority of the work there, which is why it would be very useful to get upload access to these packages; I can complete maintenance work for the Qt packages in 18.04 (all of them) while working to reduce the delta with Debian in the development release.


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


Dmitry Shachnev (mitya57)

Hash: SHA512

During the last release cycle Simon has been helping me a lot with transition
from Qt 5.7 to 5.9. This cycle he does most of the maintenance work himself,
including transitioning to newer 5.9.x releases and backporting patches from
upstream. He definitely should have upload rights for all of Qt packages.

Specific examples of working together: the transitions I mentioned above are
the main and large examples. They are usually happening via silo PPAs to
reduce brokenness period of the main archive. We are usually coordinating our
work on #ubuntu-qt channel. The code lives on salsa.debian.org and I regularly
review Simon's changes.


Costamagna Gianfranco (LocutusOfBorg)

Hash: SHA256

During the last year, I helped Simon by sponsoring qt packages
(specially for main archive, because he became MOTU between
the first and the second transition).
I sponsored some qtbase uploads, helped him and reviewed his work.
We did the 5.7 -> 5.9 transition (with other people), and a minor
5.9->5.9 point update, driven mostly by himself.

His qt skills are great, he commits the work in Debian repositories,
caring about having a syncable stack, and he is quick in fixing regressions
and backporting upstream commits.
Now we agreeded to have a delta for bionic, because 5.9 is LTS upstream,
and the 5.10 in Debian might reach EOL before it.
- From the next release he will probably transition to a mostly no-delta 5.10
or 5.12 release.

I trust his qt stuff, and most important, I'm happy with his work, because
when he is not confident about something, he asks other people for help.


Timo Jyrinki (Mirv)

Hash: SHA512

I enjoyed the interest and support tsimonq2 showed during at least the last 
year of my Qt maintenance work and also during the offloading of my tasks 
in spring 2017.

He seemed competent, with good communication skills and I was happy there were 
several good persons on the community side with interest and time in the 
continued maintenance of Qt in Ubuntu – where Qt still somewhat deviated from 
Debian even after cleaning up the Ubuntu Phone related extras – and Debian 
where the major work was being done.

Specifically we at least worked together in studying and resolving various 
package migration blockers related to Qt and KDE packages. Then at some
point late 2016 he wanted to help with Qt maintenance in Ubuntu and to learn 
as much as he could. He already knew a lot though as he had staged Qt releases 
in a PPA and had contribution rights to Debian Qt/KDE repositories.

I didn't need to be worried that with my non-existent free time and new 
day-time work I couldn't contribute anymore for now. And it seems he and 
others have done a great job, I'm particularly happy seeing Qt LTS point 
release in Ubuntu LTS!

Version: GnuPG v1


Rik Mills (acheronuk)

Hash: SHA256

I fully support this application. 

Since Simon has been doing that majority of maintenance and transitions for Qt,
I have noticed few major problems, and where they have existed they have been
handled in a professional and competent manner.

I would echo the comments from others that Simon does not hesitate to ask for
help and advice where this is needed, and his judgement as to when this is
required seems sound.


Marius Gripsgard

Simon has been helping us out at UBports and he has done great work so far!


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

tsimonq2/Applications/Qt5Uploader (last edited 2018-02-27 15:37:05 by tsimonq2)