Re: [trinity-devel] Press

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