[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-release-team
Subject:    Re: Release Candidate 2 and regressions
From:       Martin Koller <kollix () aon ! at>
Date:       2012-01-02 11:19:45
Message-ID: 201201021219.46232.kollix () aon ! at
[Download RAW message or body]

[Attachment #2 (multipart/signed)]

[Attachment #4 (multipart/mixed)]


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


["kmail1.png" (image/png)]
["kmail2.png" (image/png)]
["signature.asc" (application/pgp-signature)]

_______________________________________________
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


[prev in list] [next in list] [prev in thread] [next in thread]