16 Apr
2012
16 Apr
'12
3:45 p.m.
Why not provide also a HAL based kpowersave just for
R14,
alongside with the new improved one that Tim wrote? This is a phasing out
period. After R15, we drop it entirely. That gives everyone a heck of a
lot of time to work out their issues.
That is the issue I raised. I support the new hardware detection process but I don't
want to see HAL ripped in the same move. There needs to be an overlap period. Let's
add the new interface in R14, but don't remove HAL support in R14. Do that in R15.
Document the build option requirements to build either or both. If building both causes
conflicts then document those conflicts. There remains in use some older distro releases.
They need to remain supported and that means HAL.
That's all.
I like the release mantra "make each release suck
less" and
that's what I think our goal needs to be. We can't ship a perfect
release, but we can improve from every prior release. it may not seem like
it, but many a bug has been sqaushed since November 1st. I don't have a
great gauge on this, but 187 bugs have been modified, and are resolved
since 3.5.13. barring any bugs that were modified, reopened or anything
else, 187ish bugs have been resolved. I think this is tremendous
progress. 29 bug reports sit with "Patch Avail" which I think should be all
considered release blocking in a sense. We have those patches
available, we should get them out in the wild by the next release.
When I review the bug tracker in different ways and sorting methods I too notice that we
have resolved many bugs. We should not ignore that accomplishment.
Despite that noble effort, I am observing in this restlessness that we are not addressing
long standing bugs and irritable bugs. I'll cite two bug reports, neither filed by me
but irritating to me:
922 When logging out with unsaved file, trinity does not ask to save it
859 Kaffeine does not block screensaver
The TQt layer adds to the debate because some people believe the TQt layer is part of the
problem. I can't argue against the people who say TQt has caused problems because
several times I have resolved issues with some "inadvertent TQt" cleanup. A bug
with kaffeine, for example, or more recently, getting digikam and gwenview to hook
properly against the kipi-plugins.
The discussion goes deeper than superficial cleanup.
We do not address build issues in anything resembling a timely manner. When people post
build issues to this list and receive nothing but silence, then we have a problem. This is
the developer's list. We should be filing build related bug reports only seldom. Yet
David and I often have to do the opposite because we seldom receive help in this list.
Many times David and I have asked for guidance so we can learn how to resolve similar
future issues. Silence. If not for David and me pushing our personal skills to the limit
--- to the point of exhaustion, this list would be dead. That observation in itself does
not bode well for the future of this project.
While some bug reports sit unresolved with proposed patches, I can't blindly push the
patches. I have reviewed many of those patches. Some are distro specific. Some are over my
head to understand. Some require reverting previous patches. I lack the technical
expertise to decide whether to push those remaining patches. The patches I have pushed to
GIT were trivial or easily confirmed as working on more than one distro. Somebody with the
technical expertise needs to evaluate the remaining patches.
Yet even then, despite our having had discussed the concept of a sign-off process, several
times I have posted to this list a request to review a patch and asked somebody to provide
a sign-off. Silence.
Of those patches that revert previous patching, we need to determine why the original
patch was pushed. Some "root cause analysis" is required to ensure reverting a
patch does not restore a previous bug. I have discovered several patches like that. For
myself I have reverted them in my build process, but I won't push those reverted
patches to GIT because I don't know the implications on other distros.
I am well aware that this project is fueled by volunteer efforts. The compensation each of
us receives is being able to use software that we prefer.
A challenge with many of these bug reports is each person uses the software in different
ways. Some people never experience some of the bugs because they do not use the software
in the same manner. An attitude of "works for me" only angers users.
Occasionally a bug report is PEBKAC, but most of the time the bug reports are legitimate.
People don't like thinking they are contributing to a project by filing a report only
to be ignored. I can think of some large software projects where that happens regularly.
In summary: 1) people are not seeing positive motion with the bug tracker because
important bugs remain unresolved, and 2) this list does not serve its purpose with
generating help with build and development issues.
For the record, I continue to use KDE3 more than Trinity. Why? Bugs and build issues that
remain unresolved. Despite all of my efforts I am unable to eat my own dog food. Between
the two environments, my KDE3 system is less buggy and less frustrating.
We start acting like a team and start addressing bug reports and build issues or we let
this project die. I'm willing to bust butt to make this software work --- and I have
busted butt, but I also am willing to move on. The natives are getting restless. That is
the heart of this discussion.
Darrell