[Releasing] Deprecation - we are doing that wrong

[Turunen Tuukka]

Hi,

One additional thing to note is the phasing from Done -> Deprecated -> Removed. 

It would be valuable if a functionality is marked Deprecated in at least one release of Qt before it is Removed. In some extreme case this may not work, but for most modules it should be well feasible and something we have regularly done.

The more profound question to me is why put effort into having Removed modules working with a new release. 

Yours,

	Tuukka

> -----Original Message-----
> From: Releasing [mailto:releasing-bounces at qt-project.org] On Behalf Of
> Knoll Lars
> Sent: torstaina 4. helmikuuta 2016 13.57
> To: Buddenhagen Oswald <Oswald.Buddenhagen at theqtcompany.com>;
> releasing at qt-project.org
> Subject: Re: [Releasing] Deprecation - we are doing that wrong
> 
> 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.
> 
> 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.
> 
> Like that we decouple the problems and can work on getting some source
> packages for these unsupported modules with a different time schedule.
> 
> Cheers,
> Lars
> 
> _______________________________________________
> Releasing mailing list
> Releasing at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/releasing