[Releasing] Deprecation - we are doing that wrong

[Knoll Lars]

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:

>On Thu, Feb 04, 2016 at 12:57:13PM +0100, Knoll Lars wrote:
>> On 04/02/16 12:50, "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 12:31:56PM +0100, Knoll Lars wrote:
>> >> On 04/02/16 12:23, "Releasing on behalf of Oswald Buddenhagen" <releasing-bounces at qt-project.org on behalf of oswald.buddenhagen at theqtcompany.com> wrote:
>> >> >that makes no sense. building and maintaining this parallel
>> >> >not-quite-release infrastructure would be more effort than keeping it
>> >> >building and dragging it along the normal releases. that's how we
>> >> >arrived at the previous conclusion to "soften" the removal.
>> >> 
>> >> I don’t agree. I want to get rid of things that make it harder for us to release Qt. That’s what is IMO most important, given how we have fight to get releases out.
>> >> 
>> >> And I don’t think there’s a lot of effort involved, as the CI can test these modules independently. Actually we might save ourselves at some work, as we separate the problems. At least we will have a lot less pressure with that work, as it doesn’t block anything critical.
>> >> 
>> >the effort to get it working now is just disabling the autotests for
>> >these modules during integration runs. this can be hacked into the CI
>> >within a very short time (the needed information is in exactly the
>> >patches that currently fail to integrate).
>> >
>> >this cannot be possibly more effort than would be required to do
>> >parallel releases, however minimal we try to make them. and it has a
>> >much higher pay-off beyond the next few days.
>> 
>> Disabling testing these modules has to be hacked into the CI. Disabling them from being compiled is a simple change in qt5.git, so it’s even easier.
>> 
>yes, right in this second. that's not what i call a strategy.
>
>> And seeing that we’re having these problems again and again, I believe
>> that we have a higher pay-off in the long term by removing them. They
>> aren’t part of the release, they are not really maintained, so I don’t
>> want us to have to deal with these modules to get our release out.
>>
>we already *know* that we have to do at least minimal maintenance of
>them. users have *told* us so. and for that matter, it's some very
>creative interpretation of the backwards compatibility promise to say
>that removing entire modules doesn't violate it. we tried to weasel out
>of that by saying they could continue to use the old versions with new
>qt releases. we (predictably) failed at that, so we have to deliver an
>alternative.
>
>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.

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

Lars