Please reconsider planned build breakage on new KF deprecations

[Friedrich W. H. Kossebau]

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.
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? ;)

> 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

Even worse, those breakages are connected in some people's mind to a single 
person. 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?

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?

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_doesn.
27t_compile
And yes, planned build breakage is code that does not compile (under 
circumstances).

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.

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.

Cheers
Friedrich