> 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