On Tuesday 22 February 2005 05:37 pm, Brad Templeton wrote: > 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.)
Most of the stuff that went in was either new functionality (ie, wouldn't matter _when_ they went in, either pre- or post- release) or bug fixes. I kept out stuff that I thought could be unstable. > 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.) So, development stops (since I don't really have time to look after two dev trees), and no one except the people that currently use CVS test the feature freeze. Same thing happens as it does now, unless I put out an actual release. Then, when I put out a release, people complain because it has bugs. I don't really see how it's any different than the current way I do things. > 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. Nope. =) If I can use it, I'm happy. I use CVS on my production box, updating it once a week or so. > 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. No, it's more - "If you want to ensure that bugs get fixed, use CVS." I can't quite fix bugs that don't ever happen to me and aren't reported. If people don't test CVS, then they're not going to report bugs until a release is made. > 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." Well, considering that it's not a crash and will only happen to a tiny percentage of users, no, I don't agree. > 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. <shrug> People use it, people don't. It's really all the same in the end. This whole thread is silly. There was a bug for some people in the 0.17 release. It doesn't do anything aside from cause minor irritation for a small number of the people using it. That bug is now fixed in CVS, and that fix will be in the next release (next month sometime). If someone can't wait for the next release, they can grab CVS. If they don't want to do that, they can ask one of the packagers to pull the patch that fixes it out of CVS and include it in their packages. I'll even make it easy: http://cvs.mythtv.org/cgi-bin/viewcvs.cgi/mythtv/programs/mythbackend/mainserver.cpp?r1=1.177&r2=1.178 _IF_ there was a bug that caused major useability problems for most users, then I'd put out a quick point release (ie., scheduler broken & tendency to lock up on the playback selection window - 0.15.1, or muting the right channel after a channel change - 0.9.1). Isaac _______________________________________________ mythtv-users mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
