4 Oct
2010
4 Oct
'10
1:50 a.m.
Trinity 3.5.12 has been released!
Those who are not signed up to the trinity-announce mailing list may want
to read the 3.5.12 release announcement here:
http://trinity-announce.pearsoncomputing.net/?0::5
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!
Developers who do not yet have write access to the Wiki should contact me
with their username and I will grant them write access.
When patching bugs, please assign the bug to yourself before starting work
on it. This will avoid duplication of effort caused by multiple
developers working on the same bug while not knowing of the others'
efforts.
Thank you to everyone who has volunteered; with any luck this will be the
best release of Trinity to date!
Timothy Pearson
Trinity Desktop Project
4 Oct
4 Oct
3:17 a.m.
New subject: [trinity-devel] 3.5.12 released!
On Sun, Oct 3, 2010 at 21:50, Timothy Pearson
<kb9vqf(a)pearsoncomputing.net> wrote:
Trinity 3.5.12 has been released!
Those who are not signed up to the trinity-announce mailing list may want
to read the 3.5.12 release announcement here:
http://trinity-announce.pearsoncomputing.net/?0::5
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!
Developers who do not yet have write access to the Wiki should contact me
with their username and I will grant them write access.
When patching bugs, please assign the bug to yourself before starting work
on it. This will avoid duplication of effort caused by multiple
developers working on the same bug while not knowing of the others'
efforts.
I'll get started with RPM packaging ASAP.
PS, I'll probably use build.opensuse.org to do that... Even though I
have my own local BS.
--
later, Robert Xu
3:10 p.m.
New subject: [trinity-devel] 3.5.12 released!
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
3:49 p.m.
New subject: [trinity-devel] 3.5.12 released!
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
3:54 p.m.
New subject: [trinity-devel] 3.5.12 released!
Started project on build.o.o
Contact me if you want maintainer access.
https://build.opensuse.org/project/show?project=home%3Abravoall1552%3Atrini…
On Mon, Oct 4, 2010 at 11:49, Kate Draven <borgqueen4(a)gmail.com> wrote:
Wow Darrell
Excellent bullseye.
I agree with everything.
That's a first for me.
Kate
On Monday 04 October 2010, Darrell Anderson wrote:
--
later, Robert Xu
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
5225
days inactive
5225
days old
4 comments
4 participants
participants (4)
-
Darrell Anderson -
Kate Draven -
Robert Xu -
Timothy Pearson