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