Wow Darrell Excellent bullseye. I agree with everything. That's a first for me. Kate On Monday 04 October 2010, Darrell Anderson wrote: > > 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