Nyall Dawson <nyall.daw...@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@. 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.
signature.asc
Description: PGP signature
_______________________________________________ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer