4 Oct
2010
4 Oct
'10
3:10 p.m.
Developers: this means the SVN has been thawed and
all
types of source
patches are now accepted again.
We need to set a direction for the Trinity project and the
next release.
I have put some suggestions on the project road map here:
http://trinity.pearsoncomputing.net/wiki/bin/view/Developers/RoadMap
Over the next couple of weeks we should hash out what is
important to the
next release and what is not. The bug repairs are
non-negotiable for
3.5.13; I would like everyone here to chip in some and help
get those bugs
under control if possible. Anyone can access a list
of all bugs via this
link:
http://bugs.pearsoncomputing.net/buglist.cgi?quicksearch=ALL
Everything else is up for grabs, so be sure to weigh in on
what you think
is important to see in Trinity over the next 6 months!
My vote is for heavy focus on reducing the bug and enhancement reports: the paper cuts
goal.
I appreciate the effort to move to cmake and eventually qt4. Those efforts should
continue.
Yet, if at release, 3.5.13 does not contain those options but the bug and enhancement list
is reduced significantly, Trinity still shines because of excellent stability and
professionalism. Even today with 4.5.x, reviewers and users admit that KDE4 is "not
yet there." Stability and lack of polish in certain areas are common reasons. Trinity
can avoid similar claims with the paper cuts goal.
I'm not a C++ coder, but I can build and test. I expect to provide that kind of
support as my schedule allows.
Another area that might need attention is moving all the libraries and non-core apps to
tqt. If that is not a goal, at minimum some testing is required to ensure the packages
build in the supported operating systems. For example, I am running into build issues on
Slackware. This is important because many users will not migrate or remain with
KDE3/Trinity if those non-core apps are unavailable. We should start with the most popular
packages:
amarok
basket
digikam
gtk-qt-engine
gwenview
k3b
k9copy
kaffeine
kchmviewer
kmplayer
kmyfirewall
knemo
koffice
kpowersave
krename
ksystemlog
ktorrent
I have built only some of these in Slackware but none have received any meaningful
usability testing.
A note. Any person who tackles a bug should contact the originator before closing the
ticket. The originator is the best candidate for ensuring the problem is understood and
resolved correctly. Useful communications is a challenge. The person tackling the bug
might not envision exactly what the originator described or expected. Don't presume.
I'm not a C++ programmer but I have done software development. Presuming never works.
:) Often people are unable to respond immediately. Lots of patience is required,
especially when the only form of communication is the written word through the bugzilla.
There should be careful and meaningful dialog with the originator when a bug is to be
closed as WON'T FIX.
One way or another, closing a ticket simply to count beans and crow is a sure way to
irritate end-users when the problem is not resolved. The KDE developers were and are
infamous for this kind of attitude.
Many of us are involved in the Trinity project because we do not like the direction and
management of KDE4. Let's avoid those same mistakes. Keep the customer first. Be a
geek and developer second. :)
Darrell