[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: QT_DEPRECATED_BEFORE/KF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x060000 considered harmful
From:       "Friedrich W. H. Kossebau" <kossebau () kde ! org>
Date:       2019-10-25 19:15:19
Message-ID: 2049665.tONoFL0ZuI () klux
[Download RAW message or body]

Am Donnerstag, 24. Oktober 2019, 18:52:34 CEST schrieb laurent Montel:
> Le jeudi 24 octobre 2019, 18:22:07 CEST Friedrich W. H. Kossebau a écrit :
> > Am Donnerstag, 24. Oktober 2019, 17:40:51 CEST schrieb laurent Montel:
> > > Le jeudi 24 octobre 2019, 16:53:04 CEST Friedrich W. H. Kossebau a écrit 
:
> > > > I see it still as an issue for new-comers but also oldies who want to
> > > > fix
> > > > a
> > > > bug in some application, for that checkout the master branch and first
> > > > will
> > > > have to fight a broken build, due to newer deprecated API.
> > > 
> > > As volker wrote we will fix code before to deprecate an api (or decrease
> > > KF_DISABLE_DEPRECATED_BEFORE_AND_AT on specific apps which can't build
> > > easily without deprecated methods).
> > 
> > "We"=? Who is going around to check all existing software if some API of a
> > KF module got deprecated? KDE CI also does not catch this instantly, as it
> > will not be triggered to rebuild dependent projects if there was a change
> > to a library. So those will only fail once there was another commit.
> 
> For example I rebuild all kde each week.
> And I think that other guys do the same.

Are there? I fear there are only a few, and they might not have the time then 
to do deprecated API porting. You might perhaps even be the only caring hero 
doing that. We need to clone you :)

> > Even more, for all actively worked on projects things will instantly break
> > on CI once a new API deprecation has entered stage and is spilled into the
> > Dependencies build. And people will get used to builds failing even more
> > ("possibly just a new deprecation, why do they get in my way, no time to
> > care").
> > 
> > > > IMHO also git master should always be buildable, and not have planned
> > > > breakage-due-to-new-deprecated-API.
> > > 
> > > The problem is if we must wait that people fix deprecated method without
> > > forcing a little, for sure nobody will work on it.
> > > 
> > > I can see a lot of kde apps which is not maintains (see kdegames for
> > > example). So nobody will change KF_DISABLE_DEPRECATED_BEFORE_AND_AT
> > 
> > The alternative proposed for unmaintained^Wcommunity-maintained software
> > would then be: have them break now already? And hope someone will fix it,
> > instead of just discarding it because, broken build and no-one caring?
> > While it otherwise would still be fine?
> 
> Who told you that it will keep broken ?
> If we show that it doesn't build we will fix it.
> I don't see the problem.

The problem I see is availability of resources of people. And forcing them 
into caring for deprecated API. This should be an opt-in for those happy to 
work on deprecations once they appear.

Porting away from deprecated API is a minor priority over bug fixes or 
features. 

> > > It's too bad as it's the first time that we have a method for removing
> > > deprecated methods before next big version... I remember when we
> > > switched
> > > between kde2/kde3/kde4/kde5 we made porting when we decided to switch to
> > > new version, so we didn"t test porting on current branch as we can do
> > > now.
> > > 
> > > Today we can remove deprecated method during ~ 1.5 years. But if we wait
> > > that each dev decided to increase KF_DISABLE_DEPRECATED_BEFORE_AND_AT we
> > > will arrive at the same situation as kde5 switching.
> > 
> > Why do you think that the compiler-warning approach does not work?
> 
> See all apps compile log for example and you will see a lot of compile
> warnings.
> I don't fix all compile warnings in pim*, I fixe when it breaks compile.

So you project yourself onto everyone? :) I can tell you, I care for warnings,

I would us rather have a culture where warnings are taken serious by everyone 
and cared for in reasonable time. Warnings are there for a reason. Otherwise 
we can disable them, saves resources in the build log.
Ideally this could be gamified. Too bad we lost commit-digest work, that was a 
nice way to "pay" people for their efforts by showing statistics and graphs, 
praising those who do non-bling work.

You can also see people fixing things based on reports by krazy (via EBN). 
Without the build being broken to force them to do that.

> Until now we have some deprecated warning message in Qt or KF5 and nobody
> fixed them. So I am sure that people will not lose time to fix them.

People will be annoyed by being forced to do something not immediately 
important. I am for sure.

One of the nice things with the new deprecations for KF thanks to 
ECMGenerateExportHeader is that the compiler already hints to what to do for 
porting (thanks to David F. for pushing for this to be there from the start).
This should lower the burden to react to warnings even more.

Cheers
Friedrich


[prev in list] [next in list] [prev in thread] [next in thread]