Release Candidate 2 and regressions

Mon Jan 2 11:19:45 UTC 2012

Hi Sebastian,

Thanks a lot for your quick response!

On Monday, 2. January 2012 11:37:45 Sebastian Kügler wrote:
> Hi Martin,
> 
> On Monday, January 02, 2012 10:29:54 Martin Koller wrote:
> > Please let the developers take some additional time to fix the most
> > annoying regressions before releasing.
> 
> That only helps and works if the developers / maintainers in question are 
> actually working on it. We won't delay the release until someone finds the 
> time to fix a bug, that just doesn't scale.
> 
> > Probably you could motivate the developers for a "bug fixing week" before
> > the tagging or some other way of QA.
> 
> That's honestly too much for the release team. This has to be taken up within 
> the teams. The release team doesn't take responsibility for code quality, the 
> maintainers do. If they don't, their software will look bad. Nothing the 
> release team can really do about it.

I understand. So probably what is missing then is a group of decision takers
who simply can say "yes, we are ready to release" or "no release, there are too many
glitches, we should not simply release because we scheduled a release"

I know how open source works as I'm contributing since a lot of years, but seriously -
until KDE manages to release good quality code it will not take enough momentum
for really widespread use.

> > I'm a professional software developer since > 20 years, and I would never
> > release software in such a state.
> 
> We'll have to balance here: does having regressions in non-standard components 
> or settings justify not releasing thousands of bugfixes? It's not like not 
> releasing actually helps, the opposite is true, by not releasing, we're 
> holding back many fixes that are important, and punishing developers who did 
> commit everything in time and made sure it works. That's a balance we need to 
> strike.

Yes, I understand. The downside is, that even if there are tons of fixes in components,
there are still regressions in others. And the truth is: people moan always about
bugs and blog etc. about what they found. And bad news are much simpler to spread
than good news. I'd like to avoid statements in some news like "KDE 4.8: nothing but
regressions".
The point is that once you get a bad reputation it is very hard to get rid of it again.
(I'm still thinking about KDE 4.0 and the current situation with kdepim/akonadi)

> > Again: this is no rant! I'm just looking for damage limitation as I love
> > KDE and I'd like to be able to recommend KDE to other people as well.
> > 
> > The details (regressions) I found in the last 3 days:
> > https://bugs.kde.org/show_bug.cgi?id=290375
> > https://bugs.kde.org/show_bug.cgi?id=290373
> > https://bugs.kde.org/show_bug.cgi?id=290371
> 
> All KHTML bugs, none of which looks like a release blocker.

That depends on the defintion of "what is a release blocker". I understood your
comments above, so I can understand that these issues are not "fatal" in the way
that KDE is completely unusable, crashes always, etc.

> > https://bugs.kde.org/show_bug.cgi?id=290274 (very serious!)
> 
> I don't know if the KHTML team actually has the resources to fix these bugs, 
> but given that most people use the WebKit part anyway, I wouldn't block a 
> release.

The problem here is: kmail (probably knotes, others) are using khtml only - 
at least I know of no way to switch to WebKit in these apps.
And I think it IS very serious if you suddenly can no longer read your mails
correctly (and I'm not talking about HTML mails, since kmail internally uses
khtml to render plaintext mails as well). I attach 2 random screenshots
from kmail here to see what I mean.

> We *could* recommend switching to WebKit, or make this the default 
> engine in Konqueror, but best is probably to talk to the KHTML guys about 
> this.

The second problem with WebKit in konqueror is, when using it, you lose some
functionality you have when using khtml, e.g. the Tools menu in konqueror has
much less entries (HTML settings, validation, Adblock, ...)

> > https://bugs.kde.org/show_bug.cgi?id=290278 (probably already fixed)
> 
> Let's trust Peter here :)

Of course. But shouldn't someone test this before we say: yes, it's fixed
and therefore we can release ?
I mean: a release candidate should not have such bugs. A beta, yes. But
a RC ? no.

> 
> > https://bugs.kde.org/show_bug.cgi?id=290276
> 
> Visual glitch, not a release blocker either.

yes, in terms of "it's still usable", you're right.
In terms of "wth does this thing not obey my settings anymore" - no.
A new release should not have regressions (which are so simple to spot).

> > https://bugs.kde.org/show_bug.cgi?id=290273
> 
> Not default, no release blocker.

the same as above. It does not block my work, correct.
I still looks ugly.

> 
> > https://bugs.kde.org/show_bug.cgi?id=261325 (new problem added)
> 
> Should be a separate report, the one in this bugreport is fixed, if there's a 
> new problem, it doesn't make sense to recycle an old bugreport.
> 
> The new problem (kmix popup's slider always vertical) doesn't seem bad enough 
> to warrant delaying a release.

yes, in terms of "does not block my work", you are again correct.
In terms of "why do I need to change my habbits just because I upgraded to a newer version" - no.

> I've added "not a release blocker" to some bugs above, this doesn't mean 
> "don't care", it just means that the regression is not serious enough to 
> warrant blocking the release. I wouldn't do that lightly, especially not if 
> it's unclear if the maintainer is actually on this bug, or if it's just 
> waiting in the queue until the day arrives.

Thanks for looking so promptly onto my reports!

-- 
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail 
/\  www.asciiribbon.org   - against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.bibibest.at
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kmail1.png
Type: image/png
Size: 5327 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/release-team/attachments/20120102/e9a49a7f/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kmail2.png
Type: image/png
Size: 4420 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/release-team/attachments/20120102/e9a49a7f/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/release-team/attachments/20120102/e9a49a7f/attachment-0001.sig>