No interest in bug reports of older versions of KDEPIM/Akonadi that are not older than a year anymore?

[Martin Steigerwald]

Christophe Giboudeaux - 28.04.19, 17:07:
[…]
> On dimanche 28 avril 2019 14:45:33 CEST Martin Steigerwald wrote:
> > I disagree with that judgment.
> 
> Fine, then it's your duty to backport the fixes from the 18.12 and
> 19.04 branches in your packages.

I am not currently working as a packager in Debian Qt/KDE team.

I wonder what Sandro would think about this. He is the one doing most of 
the packaging work regarding Akonadi/KDEPIM for Debian. Packagers in 
Debian do backport (some) (critical) fixes… but all of them?

Aside from that, upstream bug tracker currently has no means to tell 
distro releases with and without backport of fixes apart. Of course, you 
can tell people to report downstream, but then I just ask you to have a 
look at the open bug reports regarding KDEPIM/Akonadi in Debian bug 
tracker. Where I often told users to report upstream… on what were clear 
upstream issues.

I totally get it: KDEPIM/Akonadi team is just a few people. KDEPIM/
Akonadi packaging in Debian is about one person, same goes with OpenSUSE 
as I just learned on IRC.

Response times to bug reports in both KDEPIM/Akonadi upstream team and 
in Debian Qt/KDE packaging team are often way, way more than 4 months. 
If you really are not interested in bug reports with any but the most 
recent release of KDEPIM/Akonadi I bet you can basically just close >80% 
of the bug reports, cause, guess who is reporting there: People who use 
Linux distros.

I did bug triaging in both bugtrackers and it often has been quite 
frustrating as for every bug I triaged, several new ones were opened.

So I sure get the frustrations regarding bug reports.

> > However, 18.08 is not even a year old.
> 
> and 18.12 + 19.04 were released since then. So, yes, it's obsolete.
> Backporting fixes to these old branches would most likely mean
> introducing regressions and/or build issues.
> 
> If a distribution wants to keep on providing obsolete software, it's
> also its responsibility to backport the fixes. (which is close to
> impossible for pim for various reasons).

By this you are basically telling Linux distributions to stop packaging 
KDEPIM as basically only few rolling distros could keep up with a 4-
monthly release cycle. Or… they would need to do it similar to how 
Debian packagers go with Firefox for example. They move from one ESR 
release to the next as it would be too much workload for them to 
backport fixes… but well for Firefox there are ESR releases. Here Debian 
would need to move from one to the next version every four months.

I am mostly writing with a user / tester / triager hat on. And my 
current conclusion is: I stop investing time in that activity until I 
can retrieve a newer version of KDEPIM in Debian again. And even then I 
am not sure I invest time again… as basically I may revisit bug reports 
that have not been acted upon for more than 4 months anyway. I'd retest 
them, I reopen them, just for them to have them not acted upon another 4 
months and be outdated again.

That's okay with me, in case that is the official position of the KDEPIM 
project. Cause then I learn it is not useful at the moment to allocate 
some of my time in that way. And I'd just cause more hassle and friction 
by doing so.

I for sure hope the major recent improvements by David, Daniel and 
others to KDEPIM/Akonadi will contribute to lighten the load of new bug 
reports on KDEPIM/Akonadi. Maybe would help to get things more 
manageable again regarding keeping up with bug reports.

I see users dig deeply into database stuff in bug reports about a PIM 
software and wonder: "What is even going on here?" (no user of any PIM 
software on the planet should ever have to do that in order to fix up 
anything)

Thanks,
-- 
Martin