Message: previous - next
Month: October 2010

Re: [trinity-devel] 3.5.12 released!

From: Robert Xu <robxu9@...>
Date: Mon, 4 Oct 2010 11:54:26 -0400
Started project on build.o.o
Contact me if you want maintainer access.

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

later, Robert Xu