Re: [trinity-devel] A Proposal (was Positive press)

Always nice to read positive reviews. :-) One way we encourage such reviews is to be in the news more often. We can do something simple to help ourselves with that goal. A modest proposal: regular point releases. After releasing R14.0.0, we release bug patch updates at regular intervals. We retain our overall "release when ready" policy, but we nonetheless release point updates on a regular basis. Along with each release we send press releases to key people to keep Trinity in the news. By "regular" I mean at approximately 6 to 8 week intervals. We release sooner for serious "show stopper" bugs. Nothing embarrassing about that, many projects have such serious bug fix releases. Likewise for security patches --- they get released as soon as practical. Each point release contains bug fixes and hopefully an enhancement request resolution or two. How many bug fixes? We need to be honest with ourselves, end-users, and the press. If we release a point release with only one minor or trivial bug fix, then eventually people see through that kind of marketing veil. We don't want that image. That is, our change log should be meaningful. Yet a point release with no less than a half dozen bug fixes would seem reasonable for a small project. Not to mention that squeezing in at least one enhancement request with each point release shows improvements as well. This strategy keeps our change log looking good and reveals an active community. Activity keeps people interested in us and encourages people to join. Currently we are focused on releasing R14.0.0 this autumn. We all want R14.0.0 to be rock solid. I am using Trinity GIT daily. In my usage, I offer that we are very stable right now. Yes, there are a handful of usability bugs that need attention, but for my usage, none are "show stoppers." My system is stable and usable and --- enjoyable. Should we retain that autumn date or push for sooner? From my perspective there are many build issues on Slackware, but only two or three that are true blockers. That is, I have found work-arounds to most of the build issues. Bugs tagged as Blocker or Critical that have work-arounds could be bugs that get fixed with each point release. I could live with that --- as long as we keep pace and release point releases regularly and truly keep attacking the bugs. With many projects with major releases the developers tend to relax and disappear for a while. If we do that then we are not in the news. We should stay in the news lime light. Regular (and real) point releases will help us stay in the news. Possibly for R14.0.0 we focus on the "true" blocker bugs and the most serious usability bugs. The goal is to get us in the news yet provide a rock solid system. We keep hacking at bugs but with that first round of bugs out of the way, we initiate a soft freeze and we ask development team members and community users to start using R14 daily for usability testing. With that goal I believe we will release R14.0.0 by the end of the summer. In that respect, and on a speculative basis, say we release R14.0.0 September 15. We release R14.1.0 about 6 to 8 weeks later, or about October 31. Likewise for R14.2.0, say just before the end of the calendar year. One nice benefit about this point release strategy is we keep hacking at the bugs and enhancement requests but at a breathable pace. I believe right now when we look at the bug tracker we tend to get overwhelmed. By addressing "true" blocker bugs to help release R14.0.0, and then keep hacking away with a half dozen to dozen bugs each point release, we keep ourselves moving at a sane pace, keep ourselves in the news, and keep Trinity rock solid. This strategy might sound somewhat like "rapid development" but not really. We are not inflating our release version numbers. We are not using Trinity as a toy for development. We are not adding significant new features because mostly we are addressing bugs. Point releases are bug fixes along with an enhancement or two. Unless an enhancement changes ABI in a significant way, including such enhancements is not "rapid development" and does not require a separate branch in our source tree. This point release strategy allows us to mail press releases are regular intervals, keeps us in the news, and hopefully, encourages positive reviews, which also hopefully, adds users and developers to our community. Darrell