On Tue, Feb 22, 2005 at 06:31:38PM -0500, Isaac Richards wrote: > 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.
Of course, but I would say that even new stuff, which has not had much time for testing at all, should stay out of a "release" even if the alternative is the feature's not there at all. Even if it's my code. :-) In this case we had a bug fix -- deal with deletes when the network filesystem is temporarily not responding at the moment you try to delete -- which did not receive enough testing and so causes common messages to this list. These things happen of course, you can never entirely prevent it. But you want to do two things -- reduce them, and be able to alter the release to add in th fixes for the most common complaints (if only to stop the repeated complaints) > > > 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. No, development surely doesn't stop -- thought it does change focus to debug and testing. This is how it is on every project I've been on with good reason. What you would like to have happen here is for the binary packagers making rpms and debs and ebuilds to make a testing binary of the RC. Some people are scared but plenty of people who would not have tested CVS are now testing this code because they can just apt-get and be running. (It's extra work but even more will test it if they have an easy back-out, ie. a database change undo, or simply the ability of the old code to work with a new database) These folks find bugs. You apply the fixes to the release branch and to the dev branch. After a week or two you tell the binary packagers to get the release branch and tell the world to download it. You're not really duplicating too much effort. The cvs is, and should be a moving target. It's not for everyday users, since documentation will have fallen behind and bugs come and go on a daily basis. > > Nope. =) If I can use it, I'm happy. I use CVS on my production box, > updating it once a week or so. Well, there are indeed many motivations for coding. I'm coding features I want for myself, but I polish and document them because I want other folks to use them too. You have a "production" system as well as a dev system, but you are the lead developer. Most people don't, and so are scared of risks that will make them miss their favourite show -- such is the problem when people come to depend on software. Anyway, you can arrange releases the way you like of course. I'm just trying to expand on various motivations people have. It's also the case, as you have no doubt read, that many people get a different interpretation from the word "release" and so some of this might be solved just be being clearer that the MythTV way of releasing is to declare a snapshot when things seem stable enough. > > 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. And I do run and test from CVS, and so do many others, but many more run from binary packages, and we want their testing too. That's all.
_______________________________________________ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
