Message: previous - next
Month: October 2010

Re: [trinity-devel] 3.5.12 released!

From: Kate Draven <borgqueen4@...>
Date: Mon, 4 Oct 2010 11:49:39 -0400
Wow Darrell

Excellent bullseye. 
I agree with everything.
That's a first for me.


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:
> >
> >
> > 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:
> >
> > 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