[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1023787: State of Debian LXQt in 2022



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

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.

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.

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?

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.

--
Simon Quigley
simon@tsimonq2.net
tsimonq2 on LiberaChat and OFTC
@tsimonq2:linuxdelta.com on Matrix
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


Reply to: