Looks like we made it to Phoronix recently, but not in a very good light: http://phoronix.com/forums/showthread.php?73392-KDE-3-5-Continues-To-Live-Th...
I don't know that there is much that can be done to improve this situation; suggestions are welcome so long as they keep in mind the limited developer resources available.
Tim
On Tuesday 11 September 2012 08:44:32 Timothy Pearson wrote:
Looks like we made it to Phoronix recently, but not in a very good light: http://phoronix.com/forums/showthread.php?73392-KDE-3-5-Continues-To-Live-T hrough-The-Trinity-Desktop
I don't know that there is much that can be done to improve this situation; suggestions are welcome so long as they keep in mind the limited developer resources available.
well, I think a valid point in the critics mentioned there is the difficulty to port existing kde3 applications to trinity. maybe a howto in the wiki could help here. I'll try to contribute on this if others here agree, once R14 is out. the reason is, I did not keep track with the ever changing situation w.r. to GIT/cmake lately, as I realized these 2 are not my friends :)
werner
Am Dienstag, 11. September 2012 schrieb Werner Joss:
On Tuesday 11 September 2012 08:44:32 Timothy Pearson wrote:
Looks like we made it to Phoronix recently, but not in a very good light: http://phoronix.com/forums/showthread.php?73392-KDE-3-5-Continues-To-Live -T hrough-The-Trinity-Desktop
I don't know that there is much that can be done to improve this situation; suggestions are welcome so long as they keep in mind the limited developer resources available.
well, I think a valid point in the critics mentioned there is the difficulty to port existing kde3 applications to trinity. maybe a howto in the wiki could help here. I'll try to contribute on this if others here agree, once R14 is out. the reason is, I did not keep track with the ever changing situation w.r. to GIT/cmake lately, as I realized these 2 are not my friends :)
I was never able to compile an old KDE2 program for KDE3.5 - that much for backward compatibility.
But I would strongly suggest to advertise bugfixes on the homepage and to release buxfixes via the official repository. It's somewhat strange that a user has to include Slaveks repository to get the bugfixes.
Just my 2 cent.
Nik
On 11 September 2012 03:14, Mag. Dr. Nikolaus Klepp office@klepp.biz wrote:
Am Dienstag, 11. September 2012 schrieb Werner Joss:
On Tuesday 11 September 2012 08:44:32 Timothy Pearson wrote:
Looks like we made it to Phoronix recently, but not in a very good light: http://phoronix.com/forums/showthread.php?73392-KDE-3-5-Continues-To-Live -T hrough-The-Trinity-Desktop
I don't know that there is much that can be done to improve this situation; suggestions are welcome so long as they keep in mind the limited developer resources available.
well, I think a valid point in the critics mentioned there is the difficulty to port existing kde3 applications to trinity. maybe a howto in the wiki could help here. I'll try to contribute on this if others here agree, once R14 is out. the reason is, I did not keep track with the ever changing situation w.r. to GIT/cmake lately, as I realized these 2 are not my friends :)
I was never able to compile an old KDE2 program for KDE3.5 - that much for backward compatibility.
But I would strongly suggest to advertise bugfixes on the homepage and to release buxfixes via the official repository. It's somewhat strange that a user has to include Slaveks repository to get the bugfixes.
Just my 2 cent.
Nik
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Well first thing to say is that phoronix are mudslinging exaggerating writers. I've seen them take a single comment from a developer and write a whole article about who the entire linux desktop is on the edge of a cliff poised to jump.
Reading through the comments is pretty silly. One guy is complaining that we didn't support Lenny. That is an irrational request since the libraries and programs are ancient. Did he upgrade to a more modern distribution? no. These arguments are always rather flawed.
Nevertheless the TQT auto-naming issues are slightly embarrassing. But hopefully mostly resolved. and stability issues? Mostly resolved with 3.5.13.1
Get 3.5.13.1 out. Restore honor to the family!
Calvin
<snip>
Nevertheless the TQT auto-naming issues are slightly embarrassing. But hopefully mostly resolved. and stability issues? Mostly resolved with 3.5.13.1
As far as I know the most ridiculous failures of the renaming process have been dealt with, though I would not be surprised if a few more were lurking under the surface, just waiting to be found.
Get 3.5.13.1 out. Restore honor to the family!
Slavek, are we about ready to release? When you are done I am planning to do a mass copy of your packages into the main 3.5.13 release archive, as I see no reason to keep the original buggy 3.5.13 available to the general public.
Do I have any volunteers to write a press release for this event? I think Slavek should be mentioned as the main mover behind this point release; if it weren't for his efforts we would all still be waiting on R14 instead of being able to use a stable point release. ;-)
Tim
On Tuesday 11 of September 2012 17:17:58 Timothy Pearson wrote:
Slavek, are we about ready to release? When you are done I am planning to do a mass copy of your packages into the main 3.5.13 release archive, as I see no reason to keep the original buggy 3.5.13 available to the general public.
Do I have any volunteers to write a press release for this event?
A few days ago I stated the following list of tasks:
1) approve and include updated scripts => DONE - already included in v3.5.13-sru branch on 'tde'
2) prepare v3.5.13-sru branch on the meta-project 'tde' I have done... I'm waiting for scripts, then I'll push it => DONE - switching between branches is now simple: git checkout _branch_ && scripts/switch_all_submodules_to_head_and_clean
3) include patches to change path for documentation from kde/HTML to tde/HTML => DONE in GIT - now I include this patches into packages, build again and checking. During checking, for example, I move a manpages, which could be in conflict with KDE4 packages. Due to thorough checking it may seem that I proceed slowly.
4) ready for create tarballs and release => I would say that git tree is ready for testing with other distributions.
Once I have all the packages for Debian and Ubuntu updated and packagers for other distributions also will confirm "ready to release", release could be published. :)
I have set up an account on the wiki, so I can prepare a detailed changelog (for Etherpad is this article too long). Hovewer, report for the official announcement I can not prepare - as you know, in English, I am very weak.
Slavek --
On Tuesday 11 of September 2012 17:17:58 Timothy Pearson wrote:
Slavek, are we about ready to release? When you are done I am planning to do a mass copy of your packages into the main 3.5.13 release archive, as I see no reason to keep the original buggy 3.5.13 available to the general public.
Do I have any volunteers to write a press release for this event?
A few days ago I stated the following list of tasks:
- approve and include updated scripts
=> DONE - already included in v3.5.13-sru branch on 'tde'
- prepare v3.5.13-sru branch on the meta-project 'tde' I have done... I'm waiting for scripts, then I'll push it
=> DONE - switching between branches is now simple: git checkout _branch_ && scripts/switch_all_submodules_to_head_and_clean
- include patches to change path for documentation from kde/HTML to
tde/HTML => DONE in GIT - now I include this patches into packages, build again and checking. During checking, for example, I move a manpages, which could be in conflict with KDE4 packages. Due to thorough checking it may seem that I proceed slowly.
- ready for create tarballs and release
=> I would say that git tree is ready for testing with other distributions.
Once I have all the packages for Debian and Ubuntu updated and packagers for other distributions also will confirm "ready to release", release could be published. :)
Looks good!
I have set up an account on the wiki, so I can prepare a detailed changelog (for Etherpad is this article too long). Hovewer, report for the official announcement I can not prepare - as you know, in English, I am very weak.
Right, I am not asking you to do this. There are other members on this list who can read your master changelog and put a nice public relations face on it. ;-)
Regarding the original topic of this thread, I ran across this today: http://jehurst.wordpress.com/2012/02/23/my-last-kde-rant
I wonder how many other people just gave up after a while and don't know that TDE exists or is viable.
Tim
Regarding the original topic of this thread, I ran across this today: http://jehurst.wordpress.com/2012/02/23/my-last-kde-rant
I wonder how many other people just gave up after a while and don't know that TDE exists or is viable.
My view is few people know about Trinity. My perception is based upon reading an above average volume of daily free/libre software RSS news feeds. With consistency, KDE, GNOME, Xfce, LXDE, and Enlightenment are mentioned regularly but Trinity is not.
The complaint about KDE/GNOME developers not responding as desired can be narrowed in many ways to the introduction of features and designs that many traditional desktop users do not want. Trinity could fill that void, but only if users know that Trinity exists. Get Trinity in the news.
A similar common complaint with software development is developers introducing "cool" new features rather than focusing on bug quashing. Both are important but bug quashing should prevail. Any time a new feature is added, serious design thought must include how users can disable the new feature when not wanted. New features must not be shoved down any proverbial throats.
Trinity does not have a regular "maintenance point release" schedule to publicly prove that bugs are being seriously quashed or to keep Trinity in the news. Bug quashing (maintenance point releases) are a huge public relations benefit and are, for the most part, painless. For a small project like Trinity, a dozen or two bug fixes could constitute a maintenance bug release and keep Trinity in the news every two months.
The only way to get Trinity in the news is to get Trinity in the news. Release 3.5.13.1 as soon as practical. Coordinate and submit a realistic R14 schedule --- including tentative subsequent point releases. Get Trinity in the news.
Darrell
<snip>
Trinity does not have a regular "maintenance point release" schedule to publicly prove that bugs are being seriously quashed or to keep Trinity in the news. Bug quashing (maintenance point releases) are a huge public relations benefit and are, for the most part, painless. For a small project like Trinity, a dozen or two bug fixes could constitute a maintenance bug release and keep Trinity in the news every two months.
This is a good idea!
Slavek, if you are reading this do you think the infrastructure is in place for either you or a small team to handle cherry-picking patches from the main GIT branch on a regular basis? I don't know if you would be able/willing to commit to doing something like this, but we obviously do have a need for it.
Even better would be if we could set a fixed step-by-step cherry-pick/build/verify procedure (e.g. on the Wiki) and get another developer or two involved in the process. This should get easier after R14 is released as we won't be working around the significant renaming between the SRU and master branches.
Thoughts?
Tim
Even better would be if we could set a fixed step-by-step cherry-pick/build/verify procedure (e.g. on the Wiki) and get another developer or two involved in the process. This should get easier after R14 is released as we won't be working around the significant renaming between the SRU and master branches.
Thoughts?
How do developers in other projects support parallel branches?
Much easier for R14 and forward. I suspect any outright bug fix gets merged in both the master branch and the R14 branch. New features, API/ABI breakage, enhancements, etc. (everything) are merged into the main branch but each commit is evaluated individually before merging into point release branches. We can handle that. The bug report itself is a guide as to whether the patch should be merged to the R14 branch, but as mentioned, we need a quality control check list.
Once R14.0.0 is released we stop supporting 3.5.13. The last set of tarballs released for 3.5.13 is the end of that "branch." Anybody wanting to continue 3.5.13 will need to monitor the commit page to backport patches but that will not be a project goal. Thus we need only two GIT branches, the master development branch and the stable branch, the latter of which point release tarballs are derived.
An R14 release schedule would help. Otherwise we have no good feeling of goals or time line. Currently the number of open bug tracker items is 569.
As shared earlier:
Blocker: 15 http://bugs.trinitydesktop.org/buglist.cgi?cmdtype=runnamed&namedcmd=Blo...
Critical: 20 http://bugs.trinitydesktop.org/buglist.cgi?cmdtype=runnamed&namedcmd=Cri...
Major: 64 http://bugs.trinitydesktop.org/buglist.cgi?cmdtype=runnamed&namedcmd=Maj...
Regressions: 12 http://bugs.trinitydesktop.org/buglist.cgi?cmdtype=runnamed&namedcmd=Reg...
Build issues: 86 http://bugs.trinitydesktop.org/buglist.cgi?cmdtype=runnamed&namedcmd=Bui...
As mentioned, because of overlap in categories, resolving Blockers and Criticals resolves 17 build issues.
http://bugs.trinitydesktop.org/bugzilla/bugzilla/buglist.cgi?query_format=ad...
Several build issues have work-arounds and need not be resolved for releasing R14.0.0. They get resolved in subsequent point releases.
With 569 open bug reports, suppose all Blockers, Criticals, and Regressions are resolved to release R14.0.0. That is a total of 47 bug reports. Improve that number to 60 bug reports, which further reduces the list of open Majors and Build Issues, and we probably have our R14.0.0 release.
569 - 60 = 509 remaining open bug reports, of which 147 are enhancement/wish list requests, leaving 362 "true" bugs.
We set a goal of a minimum 20 resolved bug reports per point release. Divide 362 by 20 to create 18 theoretical point releases. We don't have to have 18 point releases, although considering other software projects, that number would not be considered high or silly. At two month intervals, 18 point releases requires 36 months, or three years.
Or, perhaps we set a project goal of 9 point releases per major release. At 9 point releases, we would be releasing a new major release every 18 months. At 9 point releases and 20+ bug reports per point release, we resolve 180+ bug reports.
In that course new changes to upstream packages will introduce new bug reports that demand attention. New usability bugs will be filed. New enhancements requested. The never ending story. Yet by establishing a schedule we can envision our progress because we have goals. We resolve bug reports at a sane pace for the size of the team because the goals are realistic and manageable. Should Trinity's popularity improve, we likely improve the numbers with each additional developer. The potential is large with significant benefits.
Darrell
Do I have any volunteers to write a press release for this event? I think Slavek should be mentioned as the main mover behind this point release; if it weren't for his efforts we would all still be waiting on R14 instead of being able to use a stable point release. ;-)
There is a press release template in etherpad:
http://trinity.etherpad.trinitydesktop.org/37
Darrell
Looks like we made it to Phoronix recently, but not in a very good light: http://phoronix.com/forums/showthread.php?73392-KDE-3-5-Continues-To-Live-Th...
I don't know that there is much that can be done to improve this situation; suggestions are welcome so long as they keep in mind the limited developer resources available.
Evaluate all reviews regardless of perceived merits or claims. When a claim is true then address the problem. When a claim is false then learn why the perception exists.
The Phoronix article and forum responses raised several questions.
Communications:
Communications is a problem of late. Often questions or suggestions are posted here and the only return is silence. There was a time when many bugs were resolved in this list without using the bug tracker. There was a time when list members helped one another.
A team leader should be active. Primarily with keeping the community informed. To coordinate. To keep things flowing.
More than one person is involved, but the perception survives that Trinity is a one person show. Create a product that encourages and reveals involvement.
Stagnation:
The bug tracker needs attention. There is no automated response so users know a bug report is read by a project member. No voting system is used to help expose contentious bugs. There is no review to ensure the severity is correct.
Trinity needs a release schedule. Support both a "release when ready" and a regular "maintenance point release" schedule. The benefits are several: Trinity remains in the news on a regular basis, bug quashing occurs at a regular pace, a schedule keeps team members actively involved to maintain a good public image, users are happy because they witness and experience regular improvements, etc.
Occasionally conversations in this list focus on enterprise usage. Enterprise usage requires regular maintenance point releases. Serious users need serious support and serious feedback. A "release when ready" goal does not prevent regular maintenance point releases. A "release when ready" goal does not mean stagnation in between major releases.
Backwards compatibility with KDE3:
A better question is whether Trinity compiles on a wide range of systems and provides the same or better feature set. Usability must be backwards compatible or improved. Any feature that worked in 3.5.10 should still work in Trinity or work better.
Backwards compatibility with older distros:
An appropriate question is defining "older distro" with respect to Trinity. A reasonable foundation is whether the distro is maintained upstream. An example is support for Debian Lenny ended February 6th, 2012. Thus, as Trinity 3.5.13 was released before that date, 3.5.13 and 3.5.13.1 should still compile on Lenny. Project members should not be expected to support GIT on Lenny.
Older distros implies older hardware:
Even if Trinity builds with older distros, which is good, Trinity is not suitable for older hardware. I can run KDE 3.5.10 on a PI and PII machine, albeit with some patience. I have given up trying to run Trinity on those machines. Granted, for some people the definition of "older hardware" might be a 1 GHz machine, but to me 32-bit hardware should be able to run 32-bit software. Bottom line is the goal of using Trinity on older hardware is an illusion and that should not be listed as a project goal. Real world minimal hardware requirements should be posted --- or provide serious investigation why Trinity is much slower on older hardware than 3.5.10.
Quality control:
Quality control in this project deserves attention. Often patches are pushed directly to GIT with little or no testing. There are no usability plans for complicated bugs or feature improvements. API/ABI changes are pushed without forewarning. Frequent rebuilding of packages in GIT is a fact of life, but communication and patience would solve these problems.
Trinity needs to support the ever-changing upstream layer. Trinity needs a new network-manager backend. Trinity needs TDEHWLIB. That focus should have been a separate development branch that eventually got back ported to the main GIT sources --- after testing and not merged in real-time. Yet that is now spilled milk. The bulk of the work for those new features seems complete. Keep that progress moving, but don't forget the bug tracker.
Trinity lacks multiple development branches. There should be a branch for 3.5.13. One for R14. One for R15. After the 3.5.13.1 release there should be a way to track subsequent patches that packagers can back port. With R14, there is not yet a way to maintain point releases, while keeping the main GIT branch focused on R15. Some patches pushed to R15 can be back ported to the next R14 point release and perhaps even 3.5.13.1.
Attitude:
Browsing through the mail list archives reveals a general dislike or hatred for all things KDE4 by many community members. By itself that is not bad, but participating in endless debates about KDE4 is futile. Every time somebody posts a message in this list with the usual KDE4 spin, there is a slew of responses that worsens the Trinity community image. I long ago placed certain email addresses on my "block list." Ignore the propaganda and baiting.
The best set of questions raised in the Phoronix forum:
So what's the plan with Trinity? Keep it where it is and just fix bugs? Or fix bugs and add functionality and improvements?
The project has no public short or long term goals. The wiki has not been updated in a long time. There have been no meaningful discussions about the topic in this list for a long time.
Recently I proposed an R14 release schedule. Strictly proposed.
Although there is a publicly stated goal of releasing R14 in fall 2012, few people will be disappointed if R14 is released later --- but only if there is noticeable and visible progress with improving R14. That is, a continual reduction in open bug reports. Software development is very much the journey and not the destination. With most software the destination is always a moving target anyway. Regular, continual hacking tends to keep users content because that is evidence of activity and progress.
R14 needs a formal API/ABI breakage freeze. Any new API/ABI breakage must be placed on the back burner or merged into a different development branch.
R14 needs a formal feature freeze to encourage serious bug quashing.
Conclusion:
Some of these problems are perception and can be resolved with better communication. Some of the problems are real and can be resolved with project goals. A lack of goals results in a lack of focus.
Improve communications. Focus on product quality. Invite new developers. Participate in mail list discussions. Resolve bug reports. Support a scheduled maintenance release plan. Get Trinity in the news more often. Stop arguing with KDE4 advocates.
The bottom line is Trinity should be useful. Buggy software is not useful. Software that is not in the news is not useful. Good software does what users want, not what developers want.
Darrell
Looks like we made it to Phoronix recently, but not in a very good light: http://phoronix.com/forums/showthread.php?73392-KDE-3-5-Continues-To-Live-Th...
I don't know that there is much that can be done to improve this situation; suggestions are welcome so long as they keep in mind the limited developer resources available.
Evaluate all reviews regardless of perceived merits or claims. When a claim is true then address the problem. When a claim is false then learn why the perception exists.
The Phoronix article and forum responses raised several questions.
Communications:
Communications is a problem of late. Often questions or suggestions are posted here and the only return is silence. There was a time when many bugs were resolved in this list without using the bug tracker. There was a time when list members helped one another.
A team leader should be active. Primarily with keeping the community informed. To coordinate. To keep things flowing.
More than one person is involved, but the perception survives that Trinity is a one person show. Create a product that encourages and reveals involvement.
Stagnation:
The bug tracker needs attention. There is no automated response so users know a bug report is read by a project member. No voting system is used to help expose contentious bugs. There is no review to ensure the severity is correct.
Trinity needs a release schedule. Support both a "release when ready" and a regular "maintenance point release" schedule. The benefits are several: Trinity remains in the news on a regular basis, bug quashing occurs at a regular pace, a schedule keeps team members actively involved to maintain a good public image, users are happy because they witness and experience regular improvements, etc.
Occasionally conversations in this list focus on enterprise usage. Enterprise usage requires regular maintenance point releases. Serious users need serious support and serious feedback. A "release when ready" goal does not prevent regular maintenance point releases. A "release when ready" goal does not mean stagnation in between major releases.
Backwards compatibility with KDE3:
A better question is whether Trinity compiles on a wide range of systems and provides the same or better feature set. Usability must be backwards compatible or improved. Any feature that worked in 3.5.10 should still work in Trinity or work better.
Backwards compatibility with older distros:
An appropriate question is defining "older distro" with respect to Trinity. A reasonable foundation is whether the distro is maintained upstream. An example is support for Debian Lenny ended February 6th, 2012. Thus, as Trinity 3.5.13 was released before that date, 3.5.13 and 3.5.13.1 should still compile on Lenny. Project members should not be expected to support GIT on Lenny.
Older distros implies older hardware:
Even if Trinity builds with older distros, which is good, Trinity is not suitable for older hardware. I can run KDE 3.5.10 on a PI and PII machine, albeit with some patience. I have given up trying to run Trinity on those machines. Granted, for some people the definition of "older hardware" might be a 1 GHz machine, but to me 32-bit hardware should be able to run 32-bit software. Bottom line is the goal of using Trinity on older hardware is an illusion and that should not be listed as a project goal. Real world minimal hardware requirements should be posted --- or provide serious investigation why Trinity is much slower on older hardware than 3.5.10.
Quality control:
Quality control in this project deserves attention. Often patches are pushed directly to GIT with little or no testing. There are no usability plans for complicated bugs or feature improvements. API/ABI changes are pushed without forewarning. Frequent rebuilding of packages in GIT is a fact of life, but communication and patience would solve these problems.
Trinity needs to support the ever-changing upstream layer. Trinity needs a new network-manager backend. Trinity needs TDEHWLIB. That focus should have been a separate development branch that eventually got back ported to the main GIT sources --- after testing and not merged in real-time. Yet that is now spilled milk. The bulk of the work for those new features seems complete. Keep that progress moving, but don't forget the bug tracker.
Trinity lacks multiple development branches. There should be a branch for 3.5.13. One for R14. One for R15. After the 3.5.13.1 release there should be a way to track subsequent patches that packagers can back port. With R14, there is not yet a way to maintain point releases, while keeping the main GIT branch focused on R15. Some patches pushed to R15 can be back ported to the next R14 point release and perhaps even 3.5.13.1.
Attitude:
Browsing through the mail list archives reveals a general dislike or hatred for all th
-
Calvin Morrison -
Darrell Anderson -
Mag. Dr. Nikolaus Klepp -
Slávek Banko -
Timothy Pearson -
Werner Joss