[Releasing] Deprecation - we are doing that wrong

[Thiago Macieira]

On quinta-feira, 4 de fevereiro de 2016 11:43:12 PST Robin Burchell wrote:
> Hi,
> 
> Well written mail :)

Hello all

Agreed, thanks for bringing this up.

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

I'd like to make a distinction here between deprecated and removed. We have 
five states, which I described more in detail in some blog back in 2011 or 
2012, which you can find for more info:
	1. Active
	2. Maintained
	3. Done
	4. Deprecated
	5. Removed

Deprecated means "don't write new code using this, begin porting away from it 
as it will be removed in the future", whereas "removed" means "breaks unless 
you port away". Now, we can have variances of deprecated, which I will not go 
into.

Specifically for modules, we promised this:
	qtwebkit		Deprecated
	qtscript		Deprecated
	qtquick1	Removed

We also tried to say that Deprecated modules would work with new releases, but 
we clearly failed to do that because of our extensive use of private APIs 
across modules, in which I include our entire buildsystem starting at 
load(qt_build_config).

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

Agreed, this is not feasible. Whether we would call this "Done" or whether 
it's a sublevel like "Deprecated with Support", is a discussion for another 
day.

Skipping B because I agree with Robin's arguments.

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

I think this level should be applied to the modules in Deprecated state. The 
minimum we need is the ability to say "it compiles".

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

Agreed on the procedure.

We should also be very aware of the fact that disabling tests completely means 
we could introduce breakages we won't find until a user hits it. I would 
counter-argue by saying that most such issues won't be caused by changes in 
the deprecated module, but by those in other module on which it depends. That 
means a failure of testing and a regular bug report.

It also means a willingness to investigate whether the regression reported 
against a deprecated module was caused by changes in other modules.

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

I wouldn't prefer this. This is only possible for Removed modules (by 
definition, actually).

Trying to make Deprecated = Removed will simply anger our users, especially 
those of qtwebkit, and make fools of us because we've been promising to keep 
compatibility. We may as well call the next release after that 6.0.

So I would say we *have* to bite the bullet and at the very least keep those 
modules compiling. It adds work, but it's work we have to do. We only need to 
find a way to do that work without introducing burden at the wrong times.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center