[Releasing] Deprecation - we are doing that wrong

[Robin Burchell]

Hi,

Well written mail :)

On Thu, Feb 4, 2016, at 09:15 AM, Jędrzej Nowacki wrote:
>  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.

Agreed. If a spade is a spade, call it a spade. If nobody is working on
it, and nobody will be working on it for valid reasons (whether
technical like QtQuick1, or business in the case of QtWebkit where AIUI
there simply aren't enough resources to dedicate the required effort to
it), then it's deprecated, whether or not that's a popular announcement
to make.

Making that announcement takes courage, I'm sure, but it gives a much
better impression to see deprecated technology that doesn't work rather
than trying to use something (because it has no obvious warning label)
and then wondering why it's massively broken. This, in turn, could give
Qt a bad reputation to newcomers who don't understand this situation
(and quite rightly so: it would be a bad one).

> There are a few problems with it:

<snip>, no disagreements here...

>  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.

I don't think this is in practice an option, because in reality this is
little more than life support. It basically means "we'll keep the lights
on and fix compilation/test failures but nothing else" which in turn
leads to the reputation hit that I already mentioned.

> 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)

This sounds like 'c' with tests kept enabled for the module itself if I
understand you right. And I don't like that option, it's very easy for
tests to fail for reasons completely outside that module's control, and
that shifts the headache from releasing onto making trivial compilation
fixes (oh, I want to remove this semicolon that is now a warning with a
new compiler, but I have to fix 60 other issues that broke in the
meantime too.. yeah, maybe I just won't bother).

> 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.

Yes, but it also reflects reality: it's deprecated. There's nobody
working on it. If nobody is working on it, there should be no real
change going on in the module itself, and the deprecation has already
indicated that we don't want to spend resources on testing and
maintaining it. So this sounds better, since it allows trivial fixes
without blocking either those fixes or releasing efforts.

It does have the obvious downside of potential breakage. Perhaps staging
should be restricted to either someone who wants to volunteer to
undertake that for that module (or maintainers, collectively), who would
be responsible for vetting changes to make sure they _are_ really just
simple compilation fix-type things.

> D. we can avoid shipping them completely

Honestly, I'd prefer this. Deprecated (to me) means zero effort
expended, but I guess there was already a decision taken to reverse this
for reasons I'm too lazy to go find out right now. I guess a combination
of C & D could also be an option: don't ship them, and disable testing
to enable easy fixes from whoever wants to volunteer to go make them.

-- 
  Robin Burchell
  robin at viroteck.net