[Releasing] Deprecation - we are doing that wrong

[Knoll Lars]

On 04/02/16 14:29, "Releasing on behalf of Oswald Buddenhagen" <releasing-bounces at qt-project.org on behalf of oswald.buddenhagen at theqtcompany.com> wrote:

>On Thu, Feb 04, 2016 at 01:30:46PM +0100, Knoll Lars wrote:
>> On 04/02/16 13:25, "Releasing on behalf of Oswald Buddenhagen" <releasing-bounces at qt-project.org on behalf of oswald.buddenhagen at theqtcompany.com> wrote:
>> >so any reasonable calculation of pay-off assumes these modules'
>> >presence until qt6.
>> 
>> The question is about where they are present. They can’t be part of
>> what we support in the future, we have already agreed on that.
>> Consequently they are not part of what we release.
>> 
>we established previously that keeping them in minimal form in the
>releases is the overall cheapest way.
>it also happens to be the most user-friendly way. win-win.

Depends on your definition of cheap. I don’t think delays to our release are cheap at all. Neither is the added stress to our engineers.
>
>> >> Like that we decouple the problems and can work on getting some source
>> >> packages for these unsupported modules with a different time schedule.
>> >> 
>> >why do you think that we'll *ever* have more time for that than right
>> >now? especially given that it will be *more* total effort if we take it
>> >out of the general process?
>> >
>> >and that doesn't even consider the user perspective on these pseudo
>> >releases ...
>> 
>> They are and should not be part of our release. They aren’t officially
>> supported, and making them compile and offering a source tarball is
>> merely a convenient service we can offer.
>>
>this borders on mocking our "legacy" users.

How’s that? I still want to provide the source tar balls. I just don’t believe a tight coupling between those and our official release is helping anybody.
>
>> The cost of them blocking our releases is what bothers me. That one is
>> what’s expensive, not making them compile in an independent effort.
>> 
>i don't see how this sort of tactical thinking makes any sense. what
>does it matter even if the release is delayed by a day by that?
>and we've alrady spent more time discussing the matter than it would
>have taken simon to implement the autotest suppression logic that would
>solve the entire issue (for now).

The ‘for now’ is the whole problem.

In any case, the most important thing is to get things working now so we can move forward.

As Jedrzej said, simply disabling the tests in qt5.git (option B) is also a short term fix, as it won’t help you for the case where the module stops compiling (as you then have to also fix all the tests). So it delays the problem and when things go wrong it’ll hit us even harder, as we then have to also fix tests. 

And usually that happens with time pressure. I want to get them out of the release process to remove exactly that time pressure on these modules.

Cheers,
Lars