Hi, From time to time we are deprecating/removing a module. Great it is normal that certain technologies fade out. We announce that the module is deprecated and removed, then people start complaining, it is also normal. Nobody want to upgrade software because it is costly. Then we get scared and we say, "ah don't worry it is deprecated, but we will keep it working for a while and we will still ship packages with it...". That in my opinion is not normal. There are a few problems with it:
1. It is simply a lie, nobody is looking into that modules, and they are constantly broken. Which fall-through to 2nd point 2. Nobody cares, nobody is fixing problems there and we know about breakages only when we want to update qt5, which should happen as often as possible, but as deprecated modules are broken, we update qt5 without them. Which fall- through to the next point 3. It affects releases, as we need to ship packages with deprecated / removed modules, we need to update them in qt5. Now someone needs to be allocated to fix the problems. That is definitely too late in the process. 4. Why we deprecate something that is in use? Before deprecation we really need to make a decision. Is a module worth to be kept? Yes, do not deprecate/remove it. No? Then make a clear cut, do not ship it. Make the source available if someone want to invest in keeping it alive then un- deprecate or re-add it. The current situation is just creative book keeping. I'm writing this because of qtquick1 that blocks qt5 (https://codereview.qt-project.org/#/c/147715/) The issue was known for a while (https://codereview.qt-project.org/#/c/142991/, https://codereview.qt-project.org/#/c/126971/1). Just "one more" fix is needed to unlock it :> I see a few options: A. we ask someone to maintain a deprecated / removed module, but then I guess it would be better to change the status to Done. B. we can disable tests run on Qt5 for deprecated / removed modules. It would allow us to make the release, but essentially a module would stay locked down as it is now (currently you need to stage a few changes in one go to pass CI) C. we can disable tests completely for such modules. So we would assume that if they compile then they are good enough. You know what are the consequences of it. D. we can avoid shipping them completely Pick your poison. I would take D but that is because of I'm in the mood of cutting problems. C is probably fine too. B is just stinking compromise which would fail soon (you need to fix a module to get build fixes...). A is beyond my powers. Cheers, Jędrek _______________________________________________ Releasing mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/releasing
