Re: Create new mailing list wine-isv?
Jeremy White wrote:
Not that I mean to sound like a pessimist, but I'm really just calling it as I see it. No offense to anyone intended. :)
This, in a nutshell, is Wine's greatest challenge (stepping even outside ISV boundaries for a minute).
I believe, either because I'm insane (the likely explanation), or because it's true, that Wine has progressed remarkably in the past 5 years, and can no longer be correctly dismissed as unstable or unusable.
I think the shift from Alpha to Beta status was a more dramatic signal that anyone really realizes; I think it marks the point where Wine can reliably be used for a broad range of purposes.
But, bluntly, we have to prove it. We have to start by continuing the drive to a solid 1.0; we have to continue helping a small number of ISVs really succeed.
And then of course comes the fun part; we have to hold that line and not let any regressions in :-/.
<Rant> Well that is a real sore spot with me. You know that I am a strong supporter of wine but it really concerns me that we have gone beta and not addressed preventing regessions from getting into our releases in any way. We currently have no freeze or notification of exactly when the next release is going to go out. Sure we had the one big code freeze just before 0.9 but then we went back to releasing without any notification. At his point even if our application maintainers test their app every day there is no way for them to prevent that regression going into the next release. We had at least one known regression creep into 0.9.3. and maybe more that could have been corrected if we had some warning. I think that going to beta without any real attempt to provide even the most basic freeze release cycle is not a good thing. At the very minimum I would think that we should know when the releases are going to happen but we do not even know that. </Rant>
But I think we can do it; it's why I'm still here.
Ditto. -- Tony Lambregts
Tony Lambregts <tony.lambregts(a)gmail.com> writes:
Well that is a real sore spot with me. You know that I am a strong supporter of wine but it really concerns me that we have gone beta and not addressed preventing regessions from getting into our releases in any way. We currently have no freeze or notification of exactly when the next release is going to go out. Sure we had the one big code freeze just before 0.9 but then we went back to releasing without any notification. At his point even if our application maintainers test their app every day there is no way for them to prevent that regression going into the next release.
The idea is that people should test the releases. The point of the beta phase is to encourage end users to test, and for this to happen they need to be able to get binary packages, which is what the releases are about. This is why I'm making releases more frequently too, so that end users are able to test effectively without having to build from CVS. The goal is not to prevent regressions between every minor point release, it's to make releases frequently enough that regressions can be found and fixed quickly, so that they don't creep into the next major release. Now, if you think that doesn't work I'm certainly open to doing things differently. What do you suggest? -- Alexandre Julliard julliard(a)winehq.org
On 12/16/05, Alexandre Julliard <julliard(a)winehq.org> wrote:
Tony Lambregts <tony.lambregts(a)gmail.com> writes:
Well that is a real sore spot with me. You know that I am a strong supporter of wine but it really concerns me that we have gone beta and not addressed preventing regessions from getting into our releases in any way. We currently have no freeze or notification of exactly when the next release is going to go out. Sure we had the one big code freeze just before 0.9 but then we went back to releasing without any notification. At his point even if our application maintainers test their app every day there is no way for them to prevent that regression going into the next release.
The idea is that people should test the releases. The point of the beta phase is to encourage end users to test, and for this to happen they need to be able to get binary packages, which is what the releases are about. This is why I'm making releases more frequently too, so that end users are able to test effectively without having to build from CVS.
The goal is not to prevent regressions between every minor point release, it's to make releases frequently enough that regressions can be found and fixed quickly, so that they don't creep into the next major release. Now, if you think that doesn't work I'm certainly open to doing things differently. What do you suggest?
Perhaps it's partly a matter of perception then. If I understand you 0.9 was a major release then, and 0.9.1 and company are minor releases, with the next major release being 1.0. So I anticipate that we will have a major freeze before 1.0 just like we had before 0.9? Since I'm pretty sure we do not have the resources to do nightly's like they did for Mozilla, then once certainly every two weeks is better than once a month. If we could count on a release every two weeks that would be ideal. That way people like me who use CVS ( or GIT) could help prevent regressions even getting into the minor releases, which in turn would encourage more people to use the minor releases. I would prefer to see that releases were done on a Tuesday, myself, since I have more free time to track down regressions on a weekend and with some luck get them fixed on Monday. IMO doing this would be very beneficial to application maintainers without really changing very much what you are currently doing. The next step up from this of course is to create a branch for bug fixes only but at this point I cannot say how beneficial that would really be. One more thing. At the rate we are using up minor numbers we will be looking at at 1.0 being released sometime in March. This seems not to bad to me since having a major release twice a year seems pretty reasonable. Are we planning on doing release candidates for 1.0? Or are we just freezing the main branch. It seems to me that with GIT having release candidates is a lot easier then it would be with CVS. -- Tony Lambregts
Tony Lambregts <tony.lambregts(a)gmail.com> writes:
Perhaps it's partly a matter of perception then.
If I understand you 0.9 was a major release then, and 0.9.1 and company are minor releases, with the next major release being 1.0. So I anticipate that we will have a major freeze before 1.0 just like we had before 0.9?
Definitely. The 0.9.x releases should be viewed as snapshots of the current tree. They should be more stable than the alpha snapshots but that's really because I'm being more reluctant to commit big changes as we move forward. And this will be more and more the case until we get to 1.0; it's a gradual freezing process, the temperature is going down a few degrees with every snapshot...
If we could count on a release every two weeks that would be ideal.
I'm planning to stick to the two weeks schedule, yes. Maybe weekly releases would be even better, but IMO that would require more automation of the release process so that the packages are available faster.
That way people like me who use CVS ( or GIT) could help prevent regressions even getting into the minor releases, which in turn would encourage more people to use the minor releases. I would prefer to see that releases were done on a Tuesday, myself, since I have more free time to track down regressions on a weekend and with some luck get them fixed on Monday. IMO doing this would be very beneficial to application maintainers without really changing very much what you are currently doing.
Well, there are usually a bunch of changes on Monday since they accumulate during the weekend, so I prefer to make releases on Wednesday or Thursday to leave some time for things to settle down.
One more thing. At the rate we are using up minor numbers we will be looking at at 1.0 being released sometime in March. This seems not to bad to me since having a major release twice a year seems pretty reasonable. Are we planning on doing release candidates for 1.0? Or are we just freezing the main branch. It seems to me that with GIT having release candidates is a lot easier then it would be with CVS.
There's no rule that says minor numbers have to be one digit ;-) I think it's likely to be 12 rather than 6 months between major releases, but we'll see... And yes, the 1.0 release will be off the main branch, that's where everybody is working so that's where 1.0 will be. After 1.0 there could of course be a 1.0.x stable branch in parallel with the development branch. -- Alexandre Julliard julliard(a)winehq.org
Am Freitag, 16. Dezember 2005 19:48 schrieb Alexandre Julliard:
The idea is that people should test the releases. The point of the beta phase is to encourage end users to test, and for this to happen they need to be able to get binary packages, which is what the releases are about. This is why I'm making releases more frequently too, so that end users are able to test effectively without having to build from CVS.
The goal is not to prevent regressions between every minor point release, it's to make releases frequently enough that regressions can be found and fixed quickly, so that they don't creep into the next major release. Now, if you think that doesn't work I'm certainly open to doing things differently. What do you suggest?
Yet, Wine had at least one huge regression that was well known for months (the windowed OpenGL issue, bug 2398). I think it didn't even come as a surprise, it was obviously known to happen due to the WM rewrite. Still, months later, there doesn't even seem to be an experimental fix. Lots of highly specialized apps are affected, applications that used to work just fine with Wine, and I know several guys that switched back to Windows because of that regression and the fact that there was next to no visible motivation to fix that issue. I think this regression should have been a blocker for 0.9. Right now, we have yet another known OpenGL regression (bug 4016) with no info when a fix can be expected. I reported another regression (bug 3734) that happened during the last months a while ago, that bug isn't even confirmed, yet. Granted, sounds like whining - I'm by no means a developer, but I check Wine for regressions almost daily, report bugs and maintain a few apps on appdb.winehq.org, and it seems previously working applications get broken faster than new applications start to work. The applications I test are not office apps or other 'generic' stuff, because those aren't that important IMHO (there are alternatives for Linux), but specialized niche applications (graphics, mostly) individuals and companies need working to be able to switch to Linux (or stay on Linux, as mentioned in the first paragraph). Ciao, Willie -- Willie Sippel //////// | Tritium Studios // | ______________________________ //// /// | http://www.tritium-studios.com <willie(a)froq.net>
On Fri, 2005-12-16 at 19:48 +0100, Alexandre Julliard wrote:
The goal is not to prevent regressions between every minor point release, it's to make releases frequently enough that regressions can be found and fixed quickly, so that they don't creep into the next major release. Now, if you think that doesn't work I'm certainly open to doing things differently. What do you suggest?
If I may make a humble suggestion, it would be to time another stable (or semi-stable), regression-proofed release to roughly coincide with the various distributions freezing schedules. Ubuntu, for instance has an upstream version freeze on Jan 19th and a Feature Freeze on Feb 2nd. In my ideal world, we would have a Wine release just before that Jan 19th deadline, go into regression-fix and bughunt mode, and then have a release come out around Feb 2nd that had no regressions relative to 0.9 and the Jan 19th release. Thanks, Scott Ritchie
Friday, December 16, 2005, 11:26:28 PM, Scott Ritchie wrote:
On Fri, 2005-12-16 at 19:48 +0100, Alexandre Julliard wrote:
The goal is not to prevent regressions between every minor point release, it's to make releases frequently enough that regressions can be found and fixed quickly, so that they don't creep into the next major release. Now, if you think that doesn't work I'm certainly open to doing things differently. What do you suggest?
If I may make a humble suggestion, it would be to time another stable (or semi-stable), regression-proofed release to roughly coincide with the various distributions freezing schedules. Ubuntu, for instance has an upstream version freeze on Jan 19th and a Feature Freeze on Feb 2nd. In my ideal world, we would have a Wine release just before that Jan 19th deadline, go into regression-fix and bughunt mode, and then have a release come out around Feb 2nd that had no regressions relative to 0.9 and the Jan 19th release.
That sounds to aggressive to me. We still a long ways away from major pieces falling into place. Most regressions you see, especially with games caused be major developments in d3d part of Wine. I don't think that will be "fixed" by then. There are number of fixes being worked on for copy-protection systems. Some have to be tested over period of time to check for any regressions. Looking at the bugzilla I can see that major effort is under way to have Picasa2 working. And we haven't seen a major flood of patches yet. Also we are near the Christmas holidays which means everything will ground to a halt here soon. So basically we will have 2 weeks to wrap things up - too short of the time to get anything major out of the way. IMHO before we can go into a code freeze we should put a status of all the major Wine parts together. To see what are we in the middle of doing. And decide what do we want to have in the next release. And what will have to wait. Vitaliy.
On Fri, 2005-12-16 at 23:45 -0700, Vitaliy Margolen wrote:
Friday, December 16, 2005, 11:26:28 PM, Scott Ritchie wrote:
On Fri, 2005-12-16 at 19:48 +0100, Alexandre Julliard wrote:
The goal is not to prevent regressions between every minor point release, it's to make releases frequently enough that regressions can be found and fixed quickly, so that they don't creep into the next major release. Now, if you think that doesn't work I'm certainly open to doing things differently. What do you suggest?
If I may make a humble suggestion, it would be to time another stable (or semi-stable), regression-proofed release to roughly coincide with the various distributions freezing schedules. Ubuntu, for instance has an upstream version freeze on Jan 19th and a Feature Freeze on Feb 2nd. In my ideal world, we would have a Wine release just before that Jan 19th deadline, go into regression-fix and bughunt mode, and then have a release come out around Feb 2nd that had no regressions relative to 0.9 and the Jan 19th release.
That sounds to aggressive to me. We still a long ways away from major pieces falling into place. Most regressions you see, especially with games caused be major developments in d3d part of Wine. I don't think that will be "fixed" by then.
Add six months, then, to time it with the next release. That sounds reasonable. Thanks, Scott Ritchie
participants (5)
-
Alexandre Julliard -
Scott Ritchie -
Tony Lambregts -
Vitaliy Margolen -
Willie Sippel