[Releasing] Deprecation - we are doing that wrong
Heikkinen Jani
jani.heikkinen at theqtcompany.com
Thu Feb 4 09:41:55 CET 2016
Hi!
And thanks for really good mail!
I also vote 'D'. It would make our live much easier and one who still wants to use those deprecated ones can get codes from git.
br,
Jani
________________________________________
Lähettäjä: Releasing <releasing-bounces at qt-project.org> käyttäjän puolestaJędrzej Nowacki <jedrzej.nowacki at theqtcompany.com>
Lähetetty: 4. helmikuuta 2016 10:15
Vastaanottaja: releasing at qt-project.org
Aihe: [Releasing] Deprecation - we are doing that wrong
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
Releasing at qt-project.org
http://lists.qt-project.org/mailman/listinfo/releasing
More information about the Releasing
mailing list