Darrell,
Your call to arms is quite convincing. A bug squashing day is in order. Currently there are alot of small problems that can be resolved easily. What is the problem? Lack of developers. Cmake migration is a seperate team so that is not impeding our efforts, a lack of C++ devels is.
Sorry for a breif response, typing on a phone is difficult.
Calvin Morrison
Darrell Anderson humanreadable@yahoo.com wrote:
When are bugs going to receive attention?
I don't eat my own dog food. Despite some enhancements, I continue using KDE 3.5.10 rather than Trinity 3.5.12.
I expended a lot of energy last autumn packaging Trinity 3.5.12 for Slackware 12.2. My personal schedule prevented further packaging efforts, but now that I again have some time, I am not motivated to package for recent releases. Why? There are many usability bugs that render Trinity frustrating. Many of which do not exist in KDE 3.5.10.
I filed bug reports for all of the problems after discussing them in this list. Not a single bug I filed in the bugzilla has been touched. I don't know C++ and that frustrates me because I can't fix the problems.
Some of the bugs in Trinity are carry overs from KDE3 and have existed a long time. Consider the bug of using kdeconfig as root user. Every time root uses kdeconfig, the applet creates a .kde folder in the system root directory. I have to add special lines to my rc.local to check and delete that directory.
Could I use Trinity despite all the usability bugs I reported? I could but I won't. For example, the kdesu bugs I reported leave me quite frustrated. I use kdesu many times each day and that tool works as expected in KDE 3.5.10.
A primary reason cited by many people for liking KDE3 is the desktop is highly configurable yet simple. No cruft like KDE4. People do not have to run a sqlite database in the background just to check email. People running KDE3 are not interested in a social or semantic desktop. Reading reviews and comments indicate overwhelmingly that many users detest Nepomuk, Strigi, and Akonadi. KDE3 is far more configurable than Xfce or LXDE without the cruft of KDE4. KDE3 can be run on more older hardware than KDE4 can ever hope. In other words, KDE3 is already a good desktop. Hence the dismay by many with the utter abandonment by the developers.
Trinity brought hope to such users. Many users of Trinity and KDE 3.5.10 do not want additional bling. They want a highly configurable yet stable desktop. In other words, the immediate focus should be bug quashing.
I appreciate the effort to move to a more modern build environment with cmake and interoperability with QT4. Those are good long-term goals and should continue, but I suspect those efforts have little to nothing to do with the immediacy of swatting bugs. Usability bugs are solved at the code level and not the build level.
If the reason for not quashing bugs is a lack of C++ coders, then Trinity is doomed right now.
My Slackware 12.2 system remains usable. Yet as time moves forward I cannot install or update certain packages because of the typical but awful lack of backwards compatibility found in free/libre software. Therefore I am facing the unpleasant decision of updating to a more recent release of Slackware. That means moving to a different desktop environment. I don't relish that decision, which is why I supported Trinity.
With the lack of bug quashing my enthusiasm for Trinity has diminished. Time for the rubber to meet the road. I am studying KDE4 and preparing for a possible migration. I would rather support Trinity but I have to face reality. So do all end-users who might prefer Trinity.
Packages must be readily available for end users. Other than Debian/(K)Ubuntu and Slackware 12.2, no other systems are listed as being supported. Such a short list supports the idea that Trinity is a niche product.
With the release of KDE 4.5.x series, and now 4.6, some people have written that KDE4 is ready for serious usage and has surpassed KDE3 in quality. Doesn't matter whether the proclamations are true or tainted --- the typical end-user believes the statements. Regrettably, such proclamations relegate Trinity to the status of niche product and the majority of users are not going to follow. Therefore any hopes of wide scale Trinity usage is fighting windmills. The only hope for Trinity is to provide a superb product for those who choose Trinity. Long-scale survival efforts such as with cmake and QT4 support are noble efforts but does nothing to push Trinity now. End-users don't care how packages are built. They only want to download and install packages. End users have to ask themselves a basic question: is Trinity a viable choice for desktop environments?
Being stable and bug-free goes a long way toward spawning interest in Trinity. As KDE4 increases in popularity and pushes Trinity further into niche product status, people will use Trinity because they do not want the massive cruft of KDE4 or the limited flexibility of Xfce and LXDE. Yet if Trinity is buggy then willingness to use Trinity disintegrates. That is now my unfortunate position.
I'm willing to support this project and have proven as much in the past. Many of the build issues that were fixed to allow building on a non-Kubuntu system were a result of my testing last summer. For many weeks last summer I think Tim and I were the only ones actively working with Trinity. I single-handedly created packages for Slackware 12.2. I can continue adding value in that respect, but I can't fix bugs without a healthy understanding of C++ and the overall desktop environment. Obtaining that level of knowledge and expertise requires many months of study.
I likely have stirred a hornet's nest with these comments. Yet so many bugs remaining untouched is a troubling sign. I am willing to try to package Trinity for the next Slackware release, but not until many bugs are quashed.
The Ubuntu people had a project called 100 Paper Cuts. I plea for the Trinity 101 Paper Cuts Project.
Darrell
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On 03/04/2011 12:33 PM, Calvin Morrison wrote:
Darrell,
Your call to arms is quite convincing. A bug squashing day is in order.
OK, I fully agree here. My concern with CMake being incomplete was that people who would otherwise be able to help squash bugs may not be able to because they can't get Trinity to build and/or install.
Let's do this: Everyone who can get Trinity to build and install from SVN please do so ASAP. I'll give everyone a week or so to do this.
Then, on 03/12/2011 or thereabouts, let's all gather on IRC and start hammering away at the bugs. I'll be there to offer any help on locating the problematic sections of code, and may even chip in some patches myself depending on time.
If the 12th does not work I'd like to hear some other suggestions :) The goal will be to create patches for as many bugs as possible on the bugtracker; patches can be posted on the appropriate bug reports for a large batch commit by samelian and I after reviewing them.
Does this sound like a good idea?
Tim
Sounds like a good idea to me. But...
Is the current effort toward supporting cmake negating building with automake? That is, can svn still be built with automake scripts or is that option now a dead end?
The wiki seems to contain the information I need to rewrite my build scripts, but I'm no developer and will need time to make that transition and fully test. The wiki states that only a handful of packages are fully tested with cmake. Does that mean Trinity is in no man's land right now with respect to building all packages? Or do some packages have to be built with cmake and others with automake? Or can either build process be used?
If I no longer can build with automake then I have to learn about cmake and revise all of my build scripts. My challenge is if automake no longer is supported in svn, then I am unable to help test any patches.
If I can still build svn with automake then I'll help test patches.
Side note to developers: please do not automatically close a report until the original filer reports the status of the patch. Let's build quality software and not just count beans. :) Also note in the bugzilla all packages that need to be rebuilt to test a specific bug report. A bug report might related to one app, but might require rebuilding more than one package.
Notice that even with a dual core machine, building the entire suite of core packages and a handful of others requires about five to six hours. Testing patches will take time, especially when new build problems arise.
Darrell
--- On Fri, 3/4/11, Timothy Pearson kb9vqf@pearsoncomputing.net wrote:
From: Timothy Pearson kb9vqf@pearsoncomputing.net Subject: Re: [trinity-devel] Bugs, bugs, bugs To: trinity-devel@lists.pearsoncomputing.net Date: Friday, March 4, 2011, 4:18 PM On 03/04/2011 12:33 PM, Calvin Morrison wrote:
Darrell,
Your call to arms is quite convincing. A bug squashing
day is in order.
OK, I fully agree here. My concern with CMake being incomplete was that people who would otherwise be able to help squash bugs may not be able to because they can't get Trinity to build and/or install.
Let's do this: Everyone who can get Trinity to build and install from SVN please do so ASAP. I'll give everyone a week or so to do this.
Then, on 03/12/2011 or thereabouts, let's all gather on IRC and start hammering away at the bugs. I'll be there to offer any help on locating the problematic sections of code, and may even chip in some patches myself depending on time.
If the 12th does not work I'd like to hear some other suggestions :) The goal will be to create patches for as many bugs as possible on the bugtracker; patches can be posted on the appropriate bug reports for a large batch commit by samelian and I after reviewing them.
Does this sound like a good idea?
Tim
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On 03/04/2011 10:03 PM, Darrell Anderson wrote:
Sounds like a good idea to me. But...
Is the current effort toward supporting cmake negating building with automake? That is, can svn still be built with automake scripts or is that option now a dead end?
Automake should work on the distributions and platforms that it originally did, i.e. autoconf <= 2.63 and automake <= 1.12 IIRC. It will not work with versions of autoconf/automake higher than that due to the unfixable problems that have forced our hasty move to CMake.
The wiki seems to contain the information I need to rewrite my build scripts, but I'm no developer and will need time to make that transition and fully test. The wiki states that only a handful of packages are fully tested with cmake. Does that mean Trinity is in no man's land right now with respect to building all packages? Or do some packages have to be built with cmake and others with automake? Or can either build process be used?
Unfortunately, the answer is yes if you do not fit into the version brackets I mentioned above. Work is progressing rapidly I am glad to say, but it will still take some time.
If I no longer can build with automake then I have to learn about cmake and revise all of my build scripts. My challenge is if automake no longer is supported in svn, then I am unable to help test any patches.
If I can still build svn with automake then I'll help test patches.
Yes you can, but only on your Slackware 12 system I think. Slackware 13 most likely bumped the autoconf/automake versions too high for Trinity to compile, just like all the other major distros.
Side note to developers: please do not automatically close a report until the original filer reports the status of the patch. Let's build quality software and not just count beans. :) Also note in the bugzilla all packages that need to be rebuilt to test a specific bug report. A bug report might related to one app, but might require rebuilding more than one package.
+1. That is bad practice. :) Now after a certain number of days/weeks with no response the bug should probably be closed as it has been abandoned, but if the original reporter responds in a timely fashion the bug status should be left alone by the developer(s).
Notice that even with a dual core machine, building the entire suite of core packages and a handful of others requires about five to six hours. Testing patches will take time, especially when new build problems arise.
Understood. I have a full build farm here and it can still take a day to rebuild all of Trinity from scratch.
Darrell
I checked the autotool versions in Slackware:
12.2: autoconf-2.63, automake-1.10.1 13.0: autoconf-2.63, automake-1.10.1 13.1: autoconf-2.65, automake-1.11.1 Current (13.2): autoconf-2.68, automake-1.11.1
If there is a bug quashing effort soon, then I'll test on 12.2 and maybe 13.0. At least then we know the bugs are resolved.
Two remaining questions:
How long until the cmake transition is complete?
How can I help test the cmake effort?
The bottom line is end users are not going to wait a long time for Trinity. KDE 4.6.1 was released yesterday. For a majority of users, each point release moves KDE3 further into memory. :(
Darrell
--- On Fri, 3/4/11, Timothy Pearson kb9vqf@pearsoncomputing.net wrote:
From: Timothy Pearson kb9vqf@pearsoncomputing.net Subject: Re: [trinity-devel] Bugs, bugs, bugs To: trinity-devel@lists.pearsoncomputing.net Date: Friday, March 4, 2011, 10:12 PM On 03/04/2011 10:03 PM, Darrell Anderson wrote:
Sounds like a good idea to me. But...
Is the current effort toward supporting cmake negating
building with automake? That is, can svn still be built with automake scripts or is that option now a dead end? Automake should work on the distributions and platforms that it originally did, i.e. autoconf <= 2.63 and automake <= 1.12 IIRC. It will not work with versions of autoconf/automake higher than that due to the unfixable problems that have forced our hasty move to CMake.
The wiki seems to contain the information I need to
rewrite my build scripts, but I'm no developer and will need time to make that transition and fully test. The wiki states that only a handful of packages are fully tested with cmake. Does that mean Trinity is in no man's land right now with respect to building all packages? Or do some packages have to be built with cmake and others with automake? Or can either build process be used? Unfortunately, the answer is yes if you do not fit into the version brackets I mentioned above. Work is progressing rapidly I am glad to say, but it will still take some time.
If I no longer can build with automake then I have to
learn about cmake and revise all of my build scripts. My challenge is if automake no longer is supported in svn, then I am unable to help test any patches.
If I can still build svn with automake then I'll help
test patches. Yes you can, but only on your Slackware 12 system I think. Slackware 13 most likely bumped the autoconf/automake versions too high for Trinity to compile, just like all the other major distros.
Side note to developers: please do not automatically
close a report until the original filer reports the status of the patch. Let's build quality software and not just count beans. :) Also note in the bugzilla all packages that need to be rebuilt to test a specific bug report. A bug report might related to one app, but might require rebuilding more than one package. +1. That is bad practice. :) Now after a certain number of days/weeks with no response the bug should probably be closed as it has been abandoned, but if the original reporter responds in a timely fashion the bug status should be left alone by the developer(s).
Notice that even with a dual core machine, building
the entire suite of core packages and a handful of others requires about five to six hours. Testing patches will take time, especially when new build problems arise. Understood. I have a full build farm here and it can still take a day to rebuild all of Trinity from scratch.
Darrell
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On Fri, Mar 4, 2011 at 5:18 PM, Timothy Pearson kb9vqf@pearsoncomputing.net wrote: <snip>
Let's do this: Everyone who can get Trinity to build and install from SVN please do so ASAP. I'll give everyone a week or so to do this.
Then, on 03/12/2011 or thereabouts, let's all gather on IRC and start hammering away at the bugs. I'll be there to offer any help on locating the problematic sections of code, and may even chip in some patches myself depending on time.
If the 12th does not work I'd like to hear some other suggestions :)
<snip>
Does this sound like a good idea?
Kinda late in the thread for the reply, but...
Being that I'm no coder and I haven't fixed my laptop yet, I'd be of no help, but I would like to follow along. I work on the 12th though. The only two days that I am generally available during the week are Tuesday and Wednesday, and an occaisional Monday evening (EDT). If there's no way to work this in (I know people usually work during the week), I can always read the IRC log, but I'd rather not read through what will likely be a huge amount of conversation, and I'd like to be able to ask some stupid questions (just for the sake of learning for myself some of the things that go on "behind the scenes of development", may help me in the future :-) ).
-
Calvin Morrison -
Darrell Anderson -
Kristopher Gamrat -
Timothy Pearson