Please reconsider planned build breakage on new KF deprecations

[Laurent Montel]

On vendredi 20 août 2021 00:26:36 CEST Friedrich W. H. Kossebau wrote:
> Am Mittwoch, 18. August 2021, 18:01:36 CEST schrieb Laurent Montel:
> > On mercredi 18 août 2021 16:27:29 CEST Friedrich W. H. Kossebau wrote:
> > > Hi,
> > > 
> > > the recent deprecations in KF master around KPluginLoader broke some PIM
> > > builds for me, due to KF_DISABLE_DEPRECATED_BEFORE_AND_AT being set to a
> > > number only matching the upcoming KF versions, thus immediately changing
> > > things when new deprecations come up.
> > 
> > For me the problem is that we mark as deprecated before porting code.
> > Volker methods was better, porting all code to new code (when it’s
> > possible) and after mark them as deprecated.
> > For the moment we mark method as deprecated and nobody port them.
> 
> "Nobody ports them" is not what I see happening across the places.

Ah ? I don’t see it for kdegames/kdeutils/kdeaccessibility/kdeadmin .

> Actually I see lots of porting, even more with the new young blood around.
> Of course not always immediately and by all contributors. But happening
> often enough that things are moving in good pace in general.
> I really think such a statement is overgeneralizing some experience of
> certain times in certain places.
> 
> And more, why only the focus on Qt5 and KF5? Why not on Akonadi & PIM
> libraries as well? How comes there is still Akonadi::AgentBase::ObserverV4?
> ;)

Because this api will not removed if we don’t port to new api.
It’s not the case for kf5 deprecated methods in kf6.

> > So using KF_DISABLE_DEPRECATED_BEFORE_AND_AT is good for it to avoiding to
> > wait x months before porting them. (as for sure I will need to port it)
> 
> My assessment is different here. It is bad, because:
> 
> As said before it has chance to turn people with little time away as they
> have to spent time on breakages when not wanting, surely does for me, I
> could have spent time yesterday but did not because things are broken.
> 
> It makes PIM look like a place where things are broken and broken again,
> worsening the reputation, making it less attractive for others (who wants to
> work on things that seem to break easily). Just look at the build breakages
> on build.kde.org triggered now. And worse, which sadly are not only
> restricted on PIM applications, but also affects other applications due to
> the Dependency builds breaking on the respective PIM parts.
> 
> Do a full rebuild of all PIM repos right now. I just did, and only build a
> subset, but these here just all failed to me (and there would be more which
> I had hacked up to build before though):
> * akonadi-contacts
> * akonadi-search
> * kidentitymanagement
> * pimcommon
> * calendarsupport
> * incidenceeditor
> * libksieve
> * kmail
> * kmail-account-wizard

It’s just because some part of https://invent.kde.org/frameworks/kservice/-/
merge_requests/53/ was not commited yet.
It’s the problem a patch was commited without making sure that all build 
correctly

> 
> Even worse, those breakages are connected in some people's mind to a single
> person.

Too bad :) as it’s not me which created this break.

> And by the amount of breakages completely shadowing all the person's
> great efforts all the time in keeping such an important project like KDEPIM
> alive and up-to-date and prepared for the future. They just see things
> blowing up again and again. They do not see all the work to prepare the
> future (as sadly things go unnoticed when going smoothly, but such is
> life).
> 
> I would like to find a way here to keep you happy as before, but also get
> everyone else more happy when contributing to PIM projects.
> 
> Are the breakages for everyone making you happy?
> How do they help in porting away from deprecations?
> Are you still the only doing the porting after all?

Yes because nobody thinks it’s important, and all will port in urgency when we 
will switch to kf6

> So could we find a way where things only fail building for you locally on
> new deprecations, while not breaking the build for everyone else, starting
> with CI and then individual people?

Easy

option(BUILD_WITH_DEPRECATED_METHOD “Build with deprecated method” OFF)

If (NOT BUILD_WITH_DEPRECATED_METHOD)
 Add_definitions(-DKF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x055600)
endif()

OFF by default for sure, as I don’t see why it’s me who must have a special 
flag.

You already removed all Add_definitions(-
DKF_DISABLE_DEPRECATED_BEFORE_AND_AT=xxxx) in all kde repo so even easy 
porting was never do... So when we will switch to kf6 we will do it in urgency 
and not incremental as it will be better.

I maintain a lot of pim* repo so I don’t see why I must change my environment 
because nobody wants to help to port to new api.

> What is your workflow where breaking builds help you to find out what needs
> new deprecated API work?
> I assume you can make use of environment flags to inject the information
> that you want builds breaking when hitting usage of deprecated API, right?
> 
> A first simple option which comes to mind is to have the compiler flag
>     -Werror=deprecated-declarations
> injected in some way for you. Thought that would hit any deprecations, not
> just target Qt or KF ones. For the latter, we might need some special cmake
> macros then. I would be willing to work on such, so everyone can have their
> own way.
> 
> Because at least for CI, having planned build breakages is a big NoNo.
> 
> While some would say that having "master always green" is a given assumption
> in most developer communities, KDE has something related also codified by
> "Never commit code that doesn't compile"*
> https://community.kde.org/Policies/Commit_Policy#Never_commit_code_that_does
> n. 27t_compile
> And yes, planned build breakage is code that does not compile (under
> circumstances).

I didn’t commited a broken code, kf5 master without deprecated support was 
broken. Don’t revert the problem.

> 
> Please enable others to contribute as well. Be aware that the current
> situation also pushes away people like me, who e.g. worked hard to turn code
> mosnsters like KDevelop by the time into code without usage of deprecated
> API (at least at the time last year before I shifted my focus away to other
> things in life, because there are too many interesting things :) ).
> Do you not want to have such people also in PIM, to share the workload? The
> current situation is not where I would stay, no spare time available for
> dealing with unneeded breakages. I rather would invest into forking perhaps.

I like the threat of "forking “ :)

> Right now things are a bit a self-feeding state:
> noobdy but one person ports away from deprecated API, because nobody but one
> person has fun dealing with a project where things randomly break when
> working on something else. That is not the goal here, is it?
> 
> Let's create a place where everybody is happy and can do their work-flow, so
> there is win-win.

See "If (NOT BUILD_WITH_DEPRECATED_METHOD)”

Regards

> 
> Cheers
> Friedrich


-- 
Laurent Montel | laurent.montel at kdab.com | KDE/Qt Senior Software Engineer 
KDAB (France) S.A.S., a KDAB Group company
Tel: France +33 (0)4 90 84 08 53, http://www.kdab.fr
KDAB - The Qt, C++ and OpenGL Experts