ubuntustudio-bugs team mailing list archive

[Damon Lynch <1873944@xxxxxxxxxxxxxxxxxx>]

Brian if you may, allow me a minute to put to one side the (important)
micro features of this issue and look at the bigger picture.

You are a professional whose job it is to manage bugs, always keeping in
mind the reality that fixes can have unintended consequences. You have
systems and processes in place that keep you sane and the operation
transparent. That's all good. It makes sense.

I develop the code, manage the project, maintain its website, write its
documentation, ingest bug reports, manage translations, attempt to make
its distribution better in whatever ways I can, etc. No one pays me
(although I occasionally receive a donation). I'm a volunteer whose time
is truly very limited. I have other things going on in my life, like my
unfinished doctoral dissertation.

(I imagine the packager for the program in Debian is also a volunteer
facing similar time constraints.)

The fact is, the Rapid Photo Downloader release in Ubuntu 20.04 is a
snapshot in time of the Rapid Photo Downloader project. That's it. There
is literally nothing special about it. Let's not be overly devoted to
it. It has a serious problem that I fixed before Ubuntu 20.04 was
released, but not quickly enough for it to make past the release freeze.
It also contains fixes for issues that are truly meaningful to a set of
users that were fixed before the 20.04 release, but again didn't make it
past the freeze. Version 0.9.24 of Rapid Photo Downloader is the most
stable release of the program I've made in the 13 years I've been
developing it. I know that empirically (reports from users) and I know
it from my experience from running the project.

So when I'm confronted with the prospect of justifying a bug fix release
in what looks like excruciating detail. . . . I hope you can see what it
looks like from my end of the process. It's all a bit much really. It's
like I'm being crushed by the process. I can't do it all. I see the
rationale for the process, but I can't cope with it. At this moment,
it's a bridge too far.

The thing is, the Rapid Photo Downloader release in Ubuntu 20.04 is a
really big deal because Ubuntu 20.04 is going to be used by so many
users for so long, and I know I'm going to get bug reports for the Rapid
Photo Downloader package in it for years to come.

And that's painful to think about. It leads to questions as to whether
the processes in place are alienating to other developers in my
position. It leads me to question whether I should be scaling back my
ambitions for the project.

In the bigger picture, I don't think Canonical wants this to happen to
this project or any other volunteer driven FOSS project.

-- 
You received this bug notification because you are a member of Ubuntu
Studio Bugs, which is subscribed to rapid-photo-downloader in Ubuntu.
Matching subscriptions: Ubuntu Studio Bugs
https://bugs.launchpad.net/bugs/1873944

Title:
  [SRU] Upgrade rapid-photo-downloader to version 0.9.24

Status in rapid-photo-downloader package in Ubuntu:
  Fix Released
Status in rapid-photo-downloader source package in Focal:
  In Progress
Status in rapid-photo-downloader source package in Groovy:
  Fix Released

Bug description:
  [Bug Description Edited June 2, 2020]

  [Impact]

  Rapid Photo Downloader 0.9.22 contains a bug that means for some
  users, it causes a segfault during startup every time it is launched.
  (Other users are unaffected. For example, I have never been able to
  replicate the bug on any of my systems.) There is no workaround for
  the bug except to upgrade it to a newer release.

  This is a report from a user who encountered the problem (left in a
  review in Ubuntu Software):

  "When I reinstalled my OS to upgrade to 20.04 (Studio), this app came
  preinstalled, but it wouldn't open. I tried uninstalling and
  reinstalling from Snap Store, but issue persisted. Installed using
  script from main website (Version 0.9.24) and works fine now."

  The backstory: Rapid Photo Downloader is written using Qt5. Earlier
  this year I improved the program to function properly on HighDPI
  screens. A side effect of this fix was that for a handful of users on
  displays with no screen scaling, a bug somewhere in the X window / Qt
  rendering chain made the program UI utterly broken. For a screenshot,
  see https://discuss.pixls.us/t/graphical-issues-on-xubuntu-18-04/17405

  My solution to this problem was to disable HighDPI support on systems
  where the screen scaling factor was set to 1.0. Why enable it when
  it's not needed, right? But this requires querying the screen scaling
  before initializing Rapid Photo Downloader's UI, because Qt5 requires
  HighDPI be set before instantiating QApplication. Unfortunately when
  running under X, Gtk and Qt/KDE use incompatible methods to enable and
  report screen scaling.

  So in sum, Rapid Photo Downloader needs to query the system's screen
  scaling before initializing its own application window, and how it
  does that depends on whether it is running in a Gtk or Qt based
  desktop.

  The bug in Rapid Photo Downloader 0.9.22 is caused by calling the
  Gtk/GDK API without first calling gtk_init() during application
  startup. Upon becoming aware of the bug, I (the application developer)
  discussed the problem with Emmanuele Bassi and Matthias Clasen, and
  they strong urged me to query screen scaling using XSETTINGS, and not
  the GTK/GDK API. They were correct. Querying XSETTINGS has fixed the
  bug.

  
  [Test Case]

  Because the bug in 0.9.22 only occurs on some systems and not others,
  it will either occur on a test system every time the program is
  started, or it will not. There appears to be no in-between.

  When the bug does occur, a segfault always results.

  If the program UI renders normally upon program startup an upgraded
  system version in a system in which 0.9.22 crashes, the problem is
  fixed.

  
  [Regression Potential] 

  If there are to be any regression, it would be in querying XSETTINGS.

  The actual code to query XSETTINGS is copied directly from Ubuntu and
  Debian developer Dmitry Shachnev's ReText program (which like Rapid
  Photo Downloader, is coded using Python and Qt5). Dmitry's code has
  been in use for five years, so it appears stable. This is the original
  source:

  https://github.com/retext-
  project/retext/blob/master/ReText/xsettings.py

  The call to query XSETTINGS in wrapped in try / except Python block
  that catches all exceptions, so the only way a problem would manifest
  in this code block would be a segfault. Knowing what might cause a
  segfault in such circumstances is well beyond my understanding of how
  X works.

  The great news is that after the bug fix, I have had no bug reports
  relating to HighDPI screen scaling or application startup. Screen
  scaling is working for those who use HighDPI screens, and for those
  who are not, the program UI renders as expected. Just as importantly,
  no user has reported a segfault during program startup in 0.9.23 or
  0.9.24 (or after startup either).

  I have tested versions 0.9.23 and 0.9.24 on as many desktop
  environments as I have been able to, both popular and obscure, using
  both X and where possible Wayland, toggling screen scaling on systems
  that allow it. The program UI renders properly in all the environments
  I tested it.

  Version 0.9.23 was released on 2020-04-16, and 0.9.24 on 2020-05-03.
  Both versions contain the bug fix for the segfault startup problem,
  but they also contain other bug fixes and translation updates. Given
  the potential of other regressions, and assuming either 0.9.23 or
  0.9.24 will be used for the SRU, I will discuss them briefly here too.

  I recommend 0.9.24 for the SRU. Compared to 0.9.22, 0.9.24 contains 9
  other bug fixes. Every fix is localized to the specific problem
  itself, and does not affect any other areas of the program. For all
  nine fixes, the problem was resolved with no follow-up issues
  reported. In all honesty, while I assume there are possibilities for
  regressions caused by these nine fixes, I am unaware of what they are!
  As far as I'm concerned, the problems are fixed, and no other problems
  have been caused because of them.

  There is a new feature in 0.9.24 which is a more realistic candidate
  for regressions: the feature to provide the use the option of
  automatically creating a tar file of the program configuration file
  and log files when submitting a bug report. See this documentation for
  an illustration:

  https://damonlynch.net/rapid/documentation/#reportproblem

  I tested the code extensively, and exceptions are caught when creating
  the tar (e.g. in case of problems such as no space left on the file
  system). But nonetheless, given the dialog automatically appears in
  case of any uncaught program exception, it's possible that an unstable
  program condition might somehow cause problems in the generation of
  the tar file. To mitigate this possibility, no compression of the
  files included in the tar is performed, and the tar itself is not
  compressed. So while a bug report tar file not being created properly
  is possible, I judge it unlikely, and if it does occur, any side
  effects should be neglible.

  No user has reported a problem using this new feature (having said
  that, I've had only one bug report in which it was used).

  [Other Info]
   
  The full changelog for all versions is available here:

  https://launchpad.net/rapid/pyqt/0.9.24/+download/CHANGES.rst

  Thank you.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rapid-photo-downloader/+bug/1873944/+subscriptions