Re: [opensuse] Re: Why Not Fix the Easy Bugs??


While simple answer to your post is:
"You don't take in account all issues, which as many simplifications in real
world lead to conclusions that may, or may not, survive more thorough
scrutiny. "

I'll take time to go trough and answer the best I can.
That will be incomplete too, but it will be based on more details and more
accurate.

On Sunday 12 April 2009 02:34:20 pm Richard wrote:
On Sun April 12 2009 1:52:46 pm Rajko M. wrote:
...
can you re-read what you wrote.
I'm very sure that anybody using "ALL" have actually no idea what he is
using, nor he tried to find equivalents.

Focusing on words like ALL or EVERYBODY in an attempt to cloud or divert
the real issues is a favorite tactic o people that Pete was responding to
and often it is successful in clouding or diverting the real, underlying
issue(s). The OP wasn't lambasting KDE4, he was saying that while
attempting to upgrade KDE3, a change in KDE4 caused a failure.

I do understand that. I just noticed that, in my opinion, one should not use
easily "all" and "everybody".

First, we usually can talk only about our experience, and we are not "all"
and "everybody".

Second, to avoid mentioned I'm looking for numbers in miscellaneous
statistics. They suprise me more often than not, which indicates that talking
from my corner of the world is not valid either as "all", nor "everybody".

He asked
the legitimate question which I paraphrase 'Why not fix bugs especially the
easy ones because I have pointed out what and where the bug lives and when
it happened'. Sven chose to make it a KDE3 vs KDE4 issue,

It is not Sven's choice to switch topic.

His first respond to original poster states (paraphrased) that Novell has no
plans to dedicate people to maintain KDE3. In current time, when everyone is
forced to rationalize, they want KDE4 to be developed as fast as possible. It
is left to openSUSE volunteers and their interest to keep KDE3 up and
running. Some people do that, trying to incorporate new stuff offered in KDE4
libs, but it obviously doesn't work well all the time for all little
conveniences we are used to.

Without looking in the code no one can tell what is more important, one
function, or security fixes in newer implementation. Is dropped function
problematic one that needs serious work to be safe, or it is just oversight
by developers. That means without knowing background, that we don't know,
claiming it is easy fix is not substantiated with anything relevant.

not an issue
that is much more fundemental to todays support and development model(s).

You worked with software where you was creator and you was able to make
decision what, when and how, it will be fixed.

The openSUSE as distribution has not that luxury.

First mainstream/upstream is deciding in all three of the questions for
majority of software included. If openSUSE developer decide to fix a bug the
way openSUSE users want and upstream doesn't accept fix, he is stuck to fix
every version after that, as long as it goes [1].

Second, distribution developers responsibility is not to fix all the bugs in
all applications they incorporate. Their responsibility is to fix only parts
they changed in upstream code in order to make applications work fine based
on common versions of libraries.


I'm talking as KDE3 user that moves KDE4 applications in File
Associations, from second to first place, and that makes me informed
about issues that people can face. The difference between applications is
by the day smaller, with more settings offered on KDE4 side. Not all
components are at the same development level, but what seems to be fairly
well completed is better than what is provided in version 3.

Again, the issue isn't one of KDE3 vs KDE4 and no one argued that KDE4 is
not progressing nicely but one could argue that until it is much further
along, it is premature to drop, even remove, a previous and essentially
complete and functional product especially for the sake of developing a
functional replacement.

KDE4 is just reaction to KDE3 status.
KDE3 had too many patchworks introduced to allow use newer hardware
capabilities, new demand for functionality, that did not exist few years ago
when ground work for old KDE was done. Maintenace of that code required too
much effort, and any improvement would mean much more work then rewriting.

Note that I don't know much about coding and what I mentioned above is what I
picked up from KDE web sites, and some comments on problems with the code are
few years old when nobody was thinking of KDE4.

I guess that anyone of developers would rather move slowly without stirring
water, if that would not mean much longer period of breaking stuff and fixing
bugs.

One of issues is also that KDE woke up somewhat late, so rush to expose KDE4
to user base to test should be understood, specially that openSUSE is one of
very few distributions that still give users option to run KDE3 as main
desktop, and KDE4 as playground.

While KDE4 2.2 is a long way ahead of earlier
versions, it still isn't ready to be jammed down peoples throats by saying
if you want to upgrade your system (kernel, drivers, other applications,
etc), you will lose the Desktop Environment that currently works well for
your needs, worse, as Sven indicated in a previous post in this thread, it
will remove previous versions. So, 11.2 will damage existing
installations if you aren't careful when you *upgrade*.

The problem is that assumption (that 11.2 will damage existing KDE3
installation) is pulled out of thin air. The installer can be designed to
refuse to update (upgrade) system without explicit user permission.


See this:
http://en.opensuse.org/KDE_Configure_Desktop/General/Desktop/Window_Shado
w itty-bitty function that never existed in KDE3.
Important if you want to tune graphical layout to perfection, not
important if you have customers that will stick with you despite
competition that offers all the same plus good look, which indicates
attention to detail.
...
No one said that KDE4 doesn't potentially offer new or even valuable
features. What has been said is that fixing bugs should be of a higher
priority than trying to add features. Fixing bugs in an earlier, but
still included in the current distribution can often prevent the same thpes
of errors from be incorporated in the new development version.

Only guys that work on KDE (and those that can read the C++) know why they
don't fix some of reported bugs. It could be that bug is in Qt libs and
already fixed in Qt 4.5 while still present in Qt 4.4 that we use with KDE
4.2.2.

The big problem is when users assume, or being pushed into assumption by
people that show some knowledge, that there is something like single block of
code called KDE4 that has errors, and it is only up to the KDE developers to
fix them.

What application developer can do if his code depend on libraries (kdelibs)
that further depend on another libraries (qtlibs) and bug is there, ie. qtlib
function doesn't work the way it is advertised in API documentation.

You can make workarounds, but when Qt devs correct problem you are stuck with
code that is incompatible. That happened with 4.2.2. In order to improve user
experience, fast, they fixed part of the application code they are
responsible for, and now you can't use Qt 4.5 with KDE 4.2.2. I'm sure that
you don't advocate this path, it is waste of time.

Unfixed
bugs are often there because of bad logic which will often be used in the
new development and thus propogate that type of bug in the new code. Of
course, the mentality of not fixing bugs in current releases because a new
one is under development won't stop the developend version from having the
same/similar bugs. Worse, once released, that becomes the 'current'
version and won't be fixed because a 'newer, more wonderous, less ancient,
etc. version is again under development so the bug will have yet another
chance to propogate.

Whole logic of above statement is in general correct, but applied to KDE it
assumes that KDE guys have no interest to create correct working code, which
is flat wrong. They are not children, many work for companies that have
interest in KDE well being, other can expect if they are good in KDE someone
will offer them employment (it happened before), so you can imagine that
majority has very good incentive not to show even remote signs of
irresponsibility that many poster here and around the Web take as primary
assumption for their claims.

Rajko, while I occasionally, even farily often, disagree with you on some
issues, I respect you because in the bigger picture, I perceive that you
are being, or trying to be, constructive. The person you responded to has
none of those virtues, nor my respect.

You already answered that in separate email.
Pete is just annoyed because things he is using doesn't work, but that will be
addressed. Not every KDE developer has the same amount of time to fix the
things, nor KDE as a whole should stop development until they are done.

I've read somewhere idea of reassigning resources, but that is not possible
with exception in some special cases.

While all developers can read and write C++, that doesn't mean that they all
know special requirements of each application.

Expecting that you can reassign email client developer to help guys handling
graphical interface, or vice versa, because they both use same programming
language is the same as expecting that mechanical engineer can handle
electronics design issues, only because they both talk English.

FWIW, I too use KDE3, have KDE4 installed and seen a lot of progress.
That isn't the real issue. I hope KDE4 succeeds my wildest hopes and even
the wildest expectations of those involved with its development, the issue
is one of priorities and attitudes and while KDE is a good example of how
not to introduce a new product, it isn't even the issue of this thread.

I'm pretty sure that KDE will make it.

Idea of small changes that break nothing is noble, but that doesn't work well
when you want to go from system designed with year 2000 hardware, as a base,
to year 2007 hardware. You have to change fundamental assumptions what you
hardware can do. Not to mention underlaying software (kernel) changes, new
services introduced since 2000, and, of course, user expectations.



[1]
The branching of OpenOffice to Go-OO http://go-oo.org/ is consequence of
something like that.

I was witness - bug reporter - where discussion on OpenOffice bugzilla was
defense of difference to MS product, for sake of difference, exposing user to
unexpected Calc behavior. It was stupid small thing about graying out Save
when file is not changed, which works fine in text editor (most of the time),
and not in Calc. The openSUSE developer agreed that Save should be available
all the time, as there is no damage if you use Save on file that is the same
as before, but upstream disagreed. The bug report there is long living, few
years old, with a lot of comments, and I don't think it will be solved
anytime soon.

Of course this periferal usability issue would not make reason for Novell to
dedicate developers time to Go-OO branch, there was many more, and many of
them substantial, I guess youcan find them somewhere on Go-OO web site.

--
Regards, Rajko
--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx

Relevant Pages