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.
