Having more regression testing of applications will help us get to 0.9. If user's can't test one day > becasue they can't compile, that means less testing. It also means we might lose that user as a >tester all together.
Very true. I'm still running 20010510 because newer ones don't run Lotus Notes anywhere near its level. I do have a CVS tree and every now and then do some testing and checking on it, but surely the completeness of this testing is questionable...
Ciao, Rob!
rob@mediasolution.it wrote:
Having more regression testing of applications will help us get to 0.9. If user's can't test one day > becasue they can't compile, that means less testing. It also means we might lose that user as a >tester all together.
Very true. I'm still running 20010510 because newer ones don't run Lotus Notes anywhere near its level. I do have a CVS tree and every now and then do some testing and checking on it, but surely the completeness of this testing is questionable...
The way I think about this, Is that the criteria for stable release should be a criteria for 0.9. By this I mean we need to define what minimum set of programs that work. Initially this could be small, say two dozen core programs and grow from there. At minimum 0.9 should be the start of stable/unstable release.
Tony Lambregts
The way I see it, you decide on a FEATURE freeze. Then you cut the stable branch. Next, you start stabilizing that branch for release, not allowing commits into that branch of new features. Once it is released, you merge the changes there into the development tree, and perform a new feature freeze for a new version. The fact that 0.9, 1.0 or 3.1415 are still a long way away is insignificant, as far as I can see it.
So, we decide that (for example) BiDi support will not be for 0.9, so all BiDi related changes are commited to the dev branch, and so on.
The problem with this model of working, as far as I understand it, is that WINE has little changes that are new features per sa, and most changes are simply a result of changes to existing infrastructure (after all, in a way, we are only following someone else's lead, not making up our own APIs).
It may still be possible to adopt this model, however. Seperate bugfixes from enhancments, and direct them at different branches. It may be a good idea (following the guitar thread) to define a set of apps that should be supported as "features", and make the above suggested distinction between what should go where based on that.
It is my experience, however, that unless someone steps up and say "We need to stop merging new stuff", the version never reaches release quality. Linux 2.4 and Debian Woody/Sid are two points to consider in this regard.
Shachar
-
rob＠mediasolution.it -
Shachar Shemesh -
Tony Lambregts