[Releasing] Deprecation - we are doing that wrong

[Jędrzej Nowacki]

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