critpath approval process seems rather broken

[Kevin Kofler]

Christoph Wickert wrote:
> But I can and I haven't seen any instructions what I should do. I am
> willing to try broken update again in order to provide more info, but I
> can only provide the info I am asked for.

Well, one thing worth testing is trying to figure out what part of kdepim or 
Akonadi causes the problem. (I wrote in the bug report that this is 
information which would be useful.) For example, downgrade, disable the 
"Kolab server" contacts source, upgrade again, does it still misbehave? If 
that's not it, you can try temporarily disabling other data sources. (For 
example, do you have akonadi-googledata installed? If so, try removing that, 
it helped for the other person who reported having this issue.)

But obviously, all this is a PITA to test, and I cannot make any promises 
about its effectiveness. What's sure is that IF this works, it will help us 
reduce the problem space from a very huge amount of code to a merely large 
amount of code.

Another thing which SOMETIMES helps debugging hangs (and only hangs; if 
you're now seeing other kinds of misbehavior, this won't be useful) is to 
send a SIGABRT to the process (using kill -SIGABRT) to trigger DrKonqi (or 
ABRT, for stuff not using DrKonqi) and get a backtrace of where it's stuck. 
But that doesn't work if DrKonqi isn't printing the backtraces properly 
(running the app in gdb can help in that case), nor if the "hang" is 
actually a result of getting stuck in the main event loop with nothing to do 
(I've seen that kind of hangs, the backtrace is useless in those cases).

It's also very hard to provide debugging instructions because the symptoms 
you report change all the time. I'm not even sure that what you're seeing is 
one bug and not several different ones.

>> The update was also in updates-testing for 11 days total and
>> had a karma of +2, with 2 -1 comments about regressions which were both
>> fixed in the version we pushed to stable, and 4 +1 comments. One of the
>> +1 votes was from a proventester, so this update would have fulfilled
>> even the stricter requirements for critical path packages.) It's hard to
>> fix an issue we cannot reproduce.
> 
> This means we need more testing rather than less, so your suggestion to
> remove "red tape" is counterproductive.

No, we don't need more testing. It's not realistically possible to test 
things more than we did. Considering the statistical incidence of the bug in 
question, we'd have needed hundreds, if not thousands, of testers to catch 
it. It's just not a commonly hit bug.

> I don't expect you to know the code but as the maintainers I expect you
> to be able to give me some debugging instructions that you would then
> use to get in touch with the developers.

I think the upstream developers would certainly be able to give you better 
instructions for debugging their code.

> I haven't met them again because I only see them once a week and when I
> do, I will try to get some help there.

Upstream also has an IRC chan, #kontact. You've been to our IRC chan to ask 
for help, why haven't you tried the upstream chan? (I actually told you on 
IRC to try talking to upstream.)

You also haven't filed an upstream bug, why? The only linked upstream bug is 
the one you say is a different issue. https://bugs.kde.org/

> As a matter of fact you pushed a very hairy update to a stable release and
> it broke for some people

It broke for 2 people (one of whom found a workaround that solved the 
problem for him) out of thousands of users.

I'm also fairly sure it fixed dozens of times more bugs than it caused.

> No, I wanted to ship the final, not the beta because I relied on my
> colleagues.

The fact is, the promised (kdepim 4.6) RC still isn't there, weeks after it 
was scheduled, let alone an actual release. Instead, we got another (very 
late) beta, after weeks of no updates at all.

And somehow, they managed to break 4.4.10 too. I don't think we should be 
the ones to blame for kdepim being broken.

        Kevin Kofler