[Releasing] Deprecation - we are doing that wrong

[Knoll Lars]

Hi Thiago,



On 05/02/16 00:17, "Releasing on behalf of Thiago Macieira" <releasing-bounces at qt-project.org on behalf of thiago.macieira at intel.com> wrote:

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

Yes, we originally had states 1-4, but we’re adding 5 now as well.
>
>Specifically for modules, we promised this:
>	qtwebkit		Deprecated
>	qtscript		Deprecated
>	qtquick1	Removed

No, we also moved qtwebkit into the Removed category. We promised to keep qtscript in Deprecated though.

Removed means the module is not part of the official release anymore, and we’re not providing it as part of the binary packages. We however agreed that we will keep those modules compiling against the latest Qt version, as a service to people that still haven’t been able to port away from them.

>
>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 think qtscript is still working fine, so the statement above is not quite true. Both qtwebkit and qtquick1 are still compiling and (apart from someone stepping up and doing further testing), that’s about what we can do for these modules.
>
>> >  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".

Deprecated is still supported, but we urge people to port away from it. So we do currently have CI including auto tests enabled for qtscript (but we might be a bit more lax about marking something as an expected failure).
>
>> 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.

Yes, this is fine for Removed modules. We check that they still compile, but nothing else.
>
>> > 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.

Again, we agreed that qtwebkit is being removed from 5.6, not that we keep it around in a deprecated state (it was marked as Deprecated in 5.5). 
>
>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.

Yes, we’ll keep webkit and quick1 compiling, but they are still removed from the official release. But we’ll provide source packages (in an unsupported folder or similar) for them that you can download and compile yourself.

Cheers,
Lars