Yet another failed KDE release?

[James Tyrer]

On 05/10/2013 10:58 AM, Ross Boylan wrote:
> On Thursday, May 09, 2013 08:32:10 PM James Tyrer wrote:
>> On 05/07/2013 02:40 PM, Ross Boylan wrote:
>>> I too am finding the reliability of KDE and its apps not what I would
>>> like, but one thing puzzles me about this complaint, the statement that
>>> bug fixing is not welcomed...
>>>
>>> On Tuesday, May 07, 2013 02:54:19 AM James Tyrer wrote:
>>>> The KDE development team appears to be interested in something other
>>>> than producing a stable release.  It really is that simple.  As a
>>>> result, the release process is not oriented towards producing a stable
>>>> release.
>>>
>>> I'm not sure if the developers would agree, though most developers would
>>> rather make new things than fix old ones.  They are supposedly fixing
>>> lots of bugs with each release; it's just there are so many.
>>
>> I have to, possibly, correct you here, and this is indicative of the
>> problem.  Is the tally of bugs fixed or of bugs closed?
> I understand that you and others ran into problems that were sufficiently
> serious and numerous to get you really annoyed.  You may think, and I might
> agree, that software shouldn't have been released in such a state.
>
> But by your own admission you don't know what going on with the bugs fixed or
> closed.  So perhaps you shouldn't blame the developers for something that you
> don't even know is happening.

I am asking you the question: fixed or closed?

> The 4.3 release notes http://www.kde.org/announcements/4.3/ refers to over
> 10,000 bugs fixed (vs 2,000 feature requests).  Now maybe they are counting
> closed for all reasons as fixed, but they said fixed.  It surely does not
> suggest a project devoting it all its resources to making new stuff.

I reference the Commit Digests which shows "Bugs Closed", not fixed:

http://commit-digest.org/issues/2013-04-28/

This is the wrong metric for merit -- the wrong contingency for 
reinforcement.

> You complained KDE doesn't care about quality, the 4.9 release notes
> http://www.kde.org/announcements/4.9/ note "he KDE Quality Team was set up
> earlier this year with a goal to improve the general levels of quality and
> stability in KDE software. .... The Team also set up a more rigorous testing
> process for releases starting with beta versions"

I do not say that KDE is not interested in quality.  That is a 
misreading of what I said.  What I said is that many developers are more 
interested in new features than a stable and bug free product.  The 
result is a product which is never more than 90% finished.

Testing is good.  But, testing does not address the type of bugs that we 
are probably discussing.  Testing can prevent regressions and it can 
check to see if new software conforms to the specifications.  Some types 
of testing can catch specific types of coding errors.  But, it can not 
find all types of bugs.

If the KDE Quality Team is really focused on quality control, this is a 
good sign.  However, there has been a KDE Quality Team for some time:

http://dot.kde.org/2004/03/02/announcing-kde-quality-team

and it wasn't exactly focused on quality control.

> In short, you seem to have taken your experiences and developed a theory of
> the motivation and goals of the developers and the project.  But your theory
> doesn't fit the facts too well.

I think that with more research you will find evidence to support my 
position.

> Maybe there is insufficient emphasis on software quality.  But you make it easy
> to ignore your criticisms when you make over the top statements that KDE
> doesn't care about quality.

Don't misunderstand ironic statements or dry humor.

>> Doesn't the existence of so many bugs tend to illustrate my point?

> Well, software has bugs.  I'm not sure a bug count is a great quality metric,
> but bug-free software is an impossible standard.

That isn't really a true statement but I take your point.  However, 
there are various types of bugs.  The type that it is correct to say 
that about are things that don't work as expected despite the fact that 
all coding is correct.  Yes, the only way to find these is to write the 
software and then find them.  On the other end of the scale are coding 
errors and code that simply can't work.  Basically code that should have 
never been placed in the code base.  It is this later type of bug that I 
am talking about.  That is what I am advocating Total Quality Management 
for developers to avoid so that they don't need to be fixed.

It is much less work in the long run to use TQM to avoid bugs entering 
the code base rather than allowing bugs (which are coding or design 
errors) to be committed and then trying to find them through testing 
(later), after the fact, by someone else (or users) and then fixing 
them.  Detroit found out that this wasn't the way to build cars -- 
wasn't the way to do quality control.

<SNIP>

> people you are insulting

Well, that is part of the problem, people taking objective analysis -- 
my expressing my opinion -- as a personal insult.  It most certainly is 
not.  No insult is meant or intended.  Not any more than a bug report 
should be taken personally.  It is simply how I think that the KDE 
project could do a better job of providing the users with the product 
that they need and want.

-- 
James Tyrer

Linux (mostly) From Scratch
___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.