> 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-Through-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.

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