[pkg-lxqt-devel] State of Debian LXQt in 2022

Tue Dec 6 05:15:05 GMT 2022

On Wed, Nov 16, 2022 at 10:23:56AM -0600, Simon Quigley wrote:
> Dear Debian Release Team, or whoever this may concern,
> 
> Let me provide some context for the current state of LXQt in Debian, and
> where the shortcomings exist in our current process, leading to a situation
> like this.
> 
> Lubuntu, an officially recognized flavor of Ubuntu, has used LXQt for our
> default desktop environment since the 18.10 release. The Debian LXQt Team at
> the time was anything but receptive to our contributions and the hard work
> we have put into Lubuntu being as polished as it is today. This was mostly
> due to the inconsistent release schedule used by LXQt upstream, since they
> have no clear release windows, as we do in Debian and Ubuntu, respectively.
> In 2022, I am now seeing a consistent release schedule for the first time.
> With LXQt being pre-1.0 software, it was incredibly difficult to justify
> shipping an LXQt stack with bugs that had been fixed upstream for months.
> Therefore, we decided to simply carry an Ubuntu delta.
> 
> Over time, a downstream-first approach, in and of itself, became difficult
> to justify. Especially with our refocus away from the i386 architecture,
> when we would encourage people to install Debian on those antiquated
> machines, they would be working with an incredibly old version of LXQt.
> There was absolutely no excuse for this: the Debian LXQt Team still existed,
> but always lagged at least one major version behind. That tends to add up
> when upstream only did a release once a year...

What do you mean for "with an incredibly old version of LXQt"?

As I check the release schedule in Debian [0] , and LXQt [1]. Buster
contains the latest LXQt release at that time, and Bullseye contains the
0.16 x LXQt release due to freeze policy [2] (soft freeze is at
2021-02-12, which is before LXQt 0.17).

Detail:

  Buster release at 2019-07-06, with LXQt 0.14.1
  Bullseye release at 2021-08-14, with LXQt 0.16.0

  LXQt 0.14 2019-01-25
  LXQt 0.15 2020-04-24
  LXQt 0.16 2020-11-04
  LXQt 0.17 2021-04-15
  LXQt 1.0.0 2021-11-05
  LXQt 1.1.0 2022-04-15
  LXQt 1.2.0 2022-11-05

[0] https://wiki.debian.org/DebianReleases
[1] https://en.wikipedia.org/wiki/LXQt
[2] https://release.debian.org/bullseye/freeze_policy.html

> Especially after becoming a Debian Developer and understanding what it takes
> firsthand, this was not something I wanted to continue. I announced that in
> a bug report simply to call out into the distance, to check if there was
> *anyone* interested in taking over the work Alf Gaida left us with, or at
> least interested in helping us in the effort. I received no such response,
> so I started uploading to Experimental, as you do when staging transitions.

Do not change the layout of debian/control, debian/copyright in
experimental. It causes problem when merging back to sid branch.
Especially when doing the transition.

> Several team members that held hats within Debian LXQt at some point started
> to step up and make questionable decisions. For example, despite becoming a
> Debian Developer in 2018, I was mentored to use symbols files for my library
> packages, to ensure ABI stability. They have been dropped, without even
> waiting for an acknowledgement or my perspective, because "they're too
> difficult to maintain." I will admit to allowing my mentee, Aaron Rainbolt,
> to make packaging changes that I *ONLY* intended on uploading to
> Experimental, with the intent of a thorough package review cycle, as I have
> done countless times within the Ubuntu infrastructure.

From Debian wiki [3]:

  For C++ libraries it is often better not to ship symbols files.

From Debian Policy 8.6.4 [4]:

  The shlibs system is a simpler alternative to the symbols system for
  declaring dependencies for shared libraries. It may be more
  appropriate for C++ libraries and other cases where tracking
  individual symbols is too difficult. ...

So the decision is practical, not questionable. The best practice in
2018 might not suitable for 2022.

[3] https://wiki.debian.org/UsingSymbolsFiles#C.2B-.2B-_libraries
[4] https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#the-shlibs-system

> Our work, despite the shortcomings, moves the needle forward for our users.
> There are so many bugfixes and great features included with the LXQt 1.1
> release, now LXQt 1.2, that for Debian *and* for Lubuntu, we should have it
> in the next stable release. Aaron and I have been quite discouraged by some
> of the recent actions by this team. Especially uploading to unstable what
> should have only been uploaded to experimental (in the case of liblxqt), it
> shows me that we hold very different technical standards, for our packaging
> and for our users. If I still were to have an opinion worth hearing in the
> team, I would have noted that upload to be bad. It looks to me as if they're
> seeing this as an act of aggression, when in reality, we've been sick and
> tired of twiddling our thumbs, waiting for Debian to adopt the packaging we
> have held for three cycles now. The scene was completely silent until we
> showed up, for years, and suddenly it seems to be an act of aggression?

The problem of liblxqt is not "uploading to unstable", it is "not
following transition [5]". liblxqt needs to be in unstable eventually so
that it can be released in Bookworm.

The act of aggression is due to Bookworm timeline [6]. At least for me.

[5] https://wiki.debian.org/Teams/ReleaseTeam/Transitions
[6] https://release.debian.org/bookworm/freeze_policy.html

> I don't enjoy these types of arguments. To me at least, they're subtracting
> from what we're here to do: make Debian better for its users. However, it's
> worth noting, for the sake of answering to the Debian Release Team, that
> this is the result of *years* of tension. To move things forward, I would be
> more than happy to prepare the Debian LXQt 1.2 transition *myself*, the
> *right* *way*, and upload it all to Unstable *myself*, to ensure the
> transition is actually done smoothly. At that point, we can try to work on a
> healthier team environment.

Does LXQt 1.2.0 require another transition? The only library which is
not the latest release is liblxqt [7], and liblxqt 1.2.0 does not need
transition.

[7] https://qa.debian.org/developer.php?email=pkg-lxqt-devel%40lists.alioth.debian.org

-- 
ChangZhuo Chen (陳昌倬) czchen@{czchen,debian}.org
http://czchen.info/
Key fingerprint = BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-lxqt-devel/attachments/20221206/95ca022f/attachment.sig>