On Tue, Feb 22, 2005 at 03:12:15PM -0500, Isaac Richards wrote: > > One idea that might make sense is to have somebody track when serious > > bug reports are low, and throw tags into the cvs server to declare that > > point a suitable testing release. > > Funnily enough, that's pretty much exactly what I do when I decide to put > together a release. I'd link to the bugzilla graph, but, the graph config > was eaten when the website switched servers a few months back. =)
I have to say I didn't get that sense. In the 2 weeks prior to the 0.17 release the traffic on the commits list was fast and furious, and it included all sorts of changes, not just bug fixes. (Part of this comes from developers who have been working on various projects and wanting them to get used by the larger user base suddenly realizing they had to get their code in quickly to make it into 0.17, I suspect.) This approach would be helped with a longer lead time, a statement months in advance along the lines that "Our goal is to feature freeze for 0.18 around the end of April, and release it whenever in May it looks most stable." (The months are up to you.) > I've announced that a release is close), then I don't think they have any > right to complain about bugs in a release, and certainly shouldn't bitch > about how I go about making releases. Well, you can never stop people from bitching of course, whether they have a right to or not. But those who develop open source code in the end want people to use their code, which means they want users to be happy, and recommending the program to others, etc. So good open source design involves being aware of the bitching as valuable feedback. The hard truth is there are many levels of users out there, and they are in a pyramid in terms of computer skills and numbers. If you tell users, "you want fewer bugs, compile from CVS" that puts a limit on the audience, even if it's true. It remains a question of where to put the priorities. Sometimes one writes code just for the pleasure of it, and the appreciation of peers. Sometimes you seek as many users as possible. You may even do the latter because it will bring in more developers to help with the former. I do believe it's worth the effort to get the crash-level bugs (I realize the user claims this is one and you don't agree) out of "releases." My own MythTV experience, as I noted, explains this. I got a pcHDTV got it working on its own then installed Myth. And the first thing I found was that it crashed to a black screen if you tuned the wrong channel. This took me back. I had heard Myth was some work to install, but crashing on a channel change was far worse than the expectations I had given. Had I not been dedicated to make it working, I can easily imagine stopping right there. Even if this was partly the fault of the pcHDTV driver. I think you don't want people to question giving up early on if you can help it.
_______________________________________________ mythtv-users mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
