> 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