Started project on build.o.o Contact me if you want maintainer access. https://build.opensuse.org/project/show?project=home%3Abravoall1552%3Atrinity On Mon, Oct 4, 2010 at 11:49, Kate Draven <borgqueen4@...> wrote: > 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 > > > -- later, Robert Xu