On Mon, Jan 27, 2020, at 11:15 PM, Cristián Maureira-Fredes wrote: > This means that you still have access to all the fixes for 5.15 > that happen after 5.15.2-3, since they will be on the dev branch. > (...) > > If there is a bug on 5.15 and not on 6.0, > a fix will be pushed to the dev branch, then cherry pick to the > commercial LTS version, but the patch will still be there, so you > can just added to your local Qt version.
Correct me if I'm wrong: 1. I find a bug in 5.15, which also happens to apply to 6.0 (in development). 2. I develop and submit a fix, and as per the branch policy, it should be submitted to dev, which means it will land in 6.0.0. 3. If the timing is right, and I do so before the LTS period starts, the fix will be backported to the 5.15 branch, and will land in, say 5.15.3, so I will get the fix in the version I found it, and I'm using at the moment. 4. If the timing is not right, the LTS period has started, so The Qt Company doesn't want to do the effort of backporting fixes anymore, unless is for paying customers (which I'm not writing in any "acid" or "teasy" way), so the fix will end up in a private branch that only Commercial licensees will receive. 5. I won't be able to submit the fix again to the 5.15 branch (even if it applies cleanly, a trivial cherry pick), because it will be locked. Last point is what really makes me immensely uncomfortable, so please prove me wrong. If The Qt Company is going to make its own branch for releasing commercial-only versions of 5.15, who cares if the rest of the community does some parallel different work on the *Qt PROJECT* infrastructure. I don't mean making releases out of it, just allowing the submitter to submit it again to a different branch, and letting the maintainer approve it or not. Just the Git+code-review hosting . If we don't have this, we could end up with random projects on Gitlab/Github, with custom cherry picks from dev applied, and the community effort wasted because it's just plain hard to coordinate for an effort like this (without starting a formal, hostile fork). That's typical for projects that end up in abandonware status after its popularity peaks on Github, not for a supposedly openly governed mature project like Qt. Worse, that's making people contributing to Qt... in exactly the opposite way that The Qt Company wanted! Note that for the most part I *do understand well* point 4. For a project, I needed to maintain my own branch of some old Qt 5.x version, which contained a cherry picked change from 5.x+1, containing a feature for dark menu bar on Mac OS. I fully needed the feature, and once I started it, I considered cherry picking some fixes as well. To some degree, I did maintain a specific Qt version for my customer, so I understand that TQtC is doing the same. What I DO NOT understand I DO NOT think it's good for Qt, specially The Qt Company, is making clear to the community than 5.15 is going to be a LTS, then going back. Because doing a private LTS for your customers is something that many other Qt-specialized companies can do as well. And we just attach our reputation to it, as big or small that might be. The Qt Company can (and should) offer some form of extra support even beyond LTS time for paying customers (I suppose they will still get support request for Qt 4 if not Qt 3), the same way that any independent developer, company or consultant does if it is approached by a customer. But done this way, backing out of it, is an abysmal way to treat the community. My 2¢, and my opinions are my own, and not necessarily the ones of my employer. Cheers. _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
