[Releasing] Deprecation - we are doing that wrong

[Knoll Lars]

Hi,

I also believe Option D (ie. We don’t ship them) is the best idea. It can’t be that modules that we said are unsupported block us from getting a release out.

Here is how I think we should do things:

We remove qtquick1 and qtwebkit from the set of modules we compile and test when doing qt5.git integrations. Like that these modules will not ever block us from getting a release out.

We know that these modules are still in use in some places, and that Linux distributions and some of our customers would appreciate some tar ball that compiles and works against 5.6, so that they can update their stack. To accommodate for this, we can spend a bit of time to get the 5.6 branch of these modules passing in CI. That can be done completely independent of our packaging and release process, and doesn’t have to happen at the same time. Once we have a version that passes CI, we take the source tar ball created by CI, put that onto our ftp server under 5.6/unsupported/qtquick1.tgz (or similar). 

This means that our 5.6 release doesn’t anymore have _any_ dependencies towards these modules. We can do some work on them independently, and then at a later state release some source tarball for them.

Cheers,
Lars




On 04/02/16 11:43, "Releasing on behalf of Robin Burchell" <releasing-bounces at qt-project.org on behalf of robin+qt at viroteck.net> wrote:

>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
>_______________________________________________
>Releasing mailing list
>Releasing at qt-project.org
>http://lists.qt-project.org/mailman/listinfo/releasing