[QGIS-Developer] QGIS LTR releases -- is it time to pull the plug?

[Greg Troxel]

Nyall Dawson <nyall.dawson at gmail.com> writes:

My comments are mostly meta...

> I'd like to start some conversation about the dire condition of the
> QGIS LTR release and what we can do to remedy/avoid this in future.
>
> If you've missed the conversation, our QGIS 3.16 windows releases have
> been completely broken for nearly a month now. 3.16.12 had a critical
> issue which caused lockups in Python code, and now 3.16.13 has
> completely broken projection handling (resulting in loss of CRS,
> hangups when opening projects, etc).

I did miss the conversation about the .13 problems, and I think I'm
subscribed to qgis-developer at .  I admit to not reading a lot of messages
carefully, as I am really here in aid of keeping the qgis packages in
pkgsrc working.

If the conversation was entirely in github issues, I would suggest that
serious things be brought up on the mailinglist, because subscribing to
everything on a repo like qgis seems only feasible for people who have
qgis development as a main focus, and thus github discussions don't
involve the wider community.

I think it is important to keep clear in all communications between "the
release is broken" (which implicates the sources for all platforms), vs
"the official binary packages (flavor X) for platofrm Y is broken".  I
would also want to have "the release" be the sources and have words like
"official binary packages of the release" be used when something that
isn't the source tarball is being talked about.

For example:

  https://blog.qgis.org/2021/11/16/qgis-ltr-3-16-13-reverted-to-3-16-11/

says "QGIS LTR 3.16.13 reverted to 3.16.11" but then in the finer
printer "This is true for Windows only as other OS will keep delivering
the latest 3.16.13.".   So this is really "On windows only,...".

(As an aside I find the download URL
  https://qgis.org/downloads/macos/qgis-macos-ltr.dmg
unclear as I can't tell what release that actually is, without
downloading and unpacking it, or going to the URL up one level and
inferring from dates, which points at .13, which makes sense.)

> - Put out a massive apology (and ask users to step up their funding to
> better maintain QGIS releases in future ;)

My view is that it's reasonable to ask people using Windows in a
non-personal environment to pay a small pseudo-license fee, because
Windows culture goes along with paying for software I don't mean to
depart from Free Software, just sort of a posted moral obligation to pay
something like 5% of what the ESRI licenses would have cost towards
maintenance.  I think the trick is to structure it somehow that it is
like a license/support fee to the above-the-nerds part of companies,
which is easier said than done.

> - Mark 3.16 as an early EOL. (I can't see anyone interested in
> resolving the actual issue, so we've no way forward here in releasing
> a "good" 3.16 release again.)

I updated pkgsrc to 3.16.13 on pkgsrc, and running it on NetBSD 9 it
seems to work just fine.  I even used geoscience plugin to create a
custom transform from a local grid and transformed data back into that.

So I don't see how it's reasonable to withdraw 3.16 from users of POSIXy
operating systems because Windows packaging is troubled.

> - Write the LTR releases off as a failed concept. (i.e. if we don't
> have the resources to maintain them properly, we shouldn't be offering
> them at all and should resort back to the single maintained release at
> any one time situation.)

I agree with previous commenters that this isn't a good approach and
won't repeat the ideas.

It's still not clear to me if there are actual problems in the 3.16.13
source tarball, or if this is about windows packages that have some
other kind of trouble.

In theory I'll create a package for the non-LTR release, but in practice
I haven't gotten to it yet, multiplexing gdal/geos/postgis/proj updates,
and now I'm looking at creating a 3.22 package to make the migration
faster when that is blessed as LTR.

It might be that the amount of structural changes in packaging is small
enough that this is easier than I think it's going to be, but I don't
know that.

> - Lower the supported period of a LTR release to 6 months?

That's very short.   To me, the point of stable releases is so that
users can avoid upgrading for some yearish at least period of time,
where "micro updates" don't count as upgrades.

I don't even see 1 year as a "long term release".  That's a medium term
release.  The "Long Term Stable" label in the GNU/Linux world tends to
apply to distributions that try to go for 5 years, with bug fixes only.

In maintaining pkgsrc, the point releases have been very fast, basically
a few minutes of work, do something else while it builds (thansk to
cache-busting revision headers), and then start it and see if it works
and then commit, maybe 20 minutes of paying attention.  Jumping branches
was a lot more the last time, and it's not the branch jump per se, but
things like new dependencies, requirements for particularly recent
versions of dependencies, and build system changes.

> - Offer "theoretical" LTR releases ONLY as source code, but leave it
> to users to compile themselves and accept responsibility for their own
> packaging of this release.

Or maybe just don't package qgis LTR for Windows.  It's a little hard to
tell, but it seems like all of the issues are about Windows.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20211116/d729f7b8/attachment.sig>