re: Lots of regressions in games in last few versions
Vitaliy wrote:
To get lots more people to try it and report bugs, so it can improve faster. This is questionable. I can point to several bug reports that have several dozen people reporting problems and that are still open for years. So just saying more bug reports results into better Wine is not true.
Sure, there are going to be hard bugs. Doesn't matter; on the whole, if we don't know about a bug, we can't fix it. And we need users to find the bugs for us, since only they really know how to use the apps.
Even targeted apps don't work perfectly - have some problems here and there. People won't stand that. They already feed up with windows...
When you get the bugs down below a certain point for a particular app, something funny happens: people start believing. And at that point they are willing to forgive a few issues.
The only loyal public Wine can have is gamers. And we still ignoring this fact.
Because it's not a fact. It's a subjective conclusion you reached, but I do not share that opinion. Gamers are just as finicky as anyone else.
Oh and the whole point of wine-1.0 - and the way it's being presented seems like a joke to me. Give me a break 4 apps?! 3 of which being direct competitors to native Linux applications! And such an old versions [97] that no one even uses them anymore.
The release criteria are more about managing people's expectations. Underpromising and overdelivering. They're *supposed* to seem modest. Doesn't mean we don't care about other apps.
If anything we should be emphasizing that the code freeze is to stabilize Wine and fix bugs. ALL bugs regardless of the app.
I rather thought we were. That's the whole point of http://wiki.winehq.org/PlatinumRegressionHunt I'm not sure what you're angry about. None of us have that much control over exactly which way wine develops. We all scratch our own itches, and it improves at its own pace. What more do you want? - Dan
Dan Kegel wrote:
I'm not sure what you're angry about. None of us have that much control over exactly which way wine develops. We all scratch our own itches, and it improves at its own pace. What more do you want?
Stability. For things to continue working once they get fixed. Which means more developers have to "support" their changes - promptly address all issues that result from their changes. IMHO this is the way project should be moving forward (past 1.0) Vitaliy.
Am Montag, 12. Mai 2008 14:29:40 schrieb Vitaliy Margolen:
Stability. For things to continue working once they get fixed. Which means more developers have to "support" their changes - promptly address all issues that result from their changes. IMHO this is the way project should be moving forward (past 1.0) That's a noble intention, but not possible in practise.
Vitaliy Margolen wrote:
Dan Kegel wrote:
I'm not sure what you're angry about. None of us have that much control over exactly which way wine develops. We all scratch our own itches, and it improves at its own pace. What more do you want?
Stability. For things to continue working once they get fixed. Which means more developers have to "support" their changes - promptly address all issues that result from their changes. IMHO this is the way project should be moving forward (past 1.0)
Then you must not be using Linux either. Bugs HAPPEN. Squashing them may not. Sort of like the cockroach that runs all over your floor. You can go on a stomping party and miss it every time and you may even attract more. However, if you use bug spray, you might kill the roach, but you might kill yourself as well. We need to do what you said, test Wine before releasing to the public. However, this is not possible given the aggressive release schedule of the project. So, we have to fix what we can and leave the rest until later. If you have a better plan, tell us. James McKenzie
On Mon, May 12, 2008 at 10:52 PM, James McKenzie <jjmckenzie51(a)sprintpcs.com> wrote:
Vitaliy Margolen wrote:
Dan Kegel wrote:
I'm not sure what you're angry about. None of us have that much control over exactly which way wine develops. We all scratch our own itches, and it improves at its own pace. What more do you want?
Stability. For things to continue working once they get fixed. Which means more developers have to "support" their changes - promptly address all issues that result from their changes. IMHO this is the way project should be moving forward (past 1.0)
Then you must not be using Linux either. Bugs HAPPEN. Squashing them may not. Sort of like the cockroach that runs all over your floor. You can go on a stomping party and miss it every time and you may even attract more. However, if you use bug spray, you might kill the roach, but you might kill yourself as well. We need to do what you said, test Wine before releasing to the public. However, this is not possible given the aggressive release schedule of the project. So, we have to fix what we can and leave the rest until later.
The purpose of the aggressive release schedule is exactly so that we get more testing exposure and regressions are caught quicker. Not enough patches come with tests, and sometimes the tests aren't comprehensive enough. Just because a fix seems obvious doesn't mean it can't surreptitiously create a regression somewhere else. It's not the job of the developer to foresee all these consequences, but it is the job of the developer to write test cases to prevent this from happening. While not all fixes are easy to test, you should put a lot of effort into figuring out any way possible to write a test case. See my fusion tests for an example of a difficult test. At the very least, more developers need to be vocal about raising the priority of regressions bugs they create, myself included. -- James Hawkins
but you might kill yourself as well. We need to do what you said, test Wine before releasing to the public. However, this is not possible given the aggressive release schedule of the project. Why is that so? I still do not see any benefit in calling it wine 1.0 at this time. What is the intention of this step? Attract more users? Well first, to use wine you have to use a *n*x system, which means either that you use a Mac (in which case you most probably are already using native versions of programs you could run under wine), a bsd/solaris system (in which case you already *know* wine because you definitly are not a newbie) or a linux distro (that has wine pre-installed almost with certainty..). So where is the market segment this is trying to reach? After all a version number IS a marketing argument, nothing more. Why a free & open source software project needs that - no clue. imho it is way cooler to have a fully fledged, functional and almost bug-free software with a pre-1.0-version... Attracting users by promising a major step forward - a finished x.0 release - that don't already come to wine by other means may backfire - a zillion useless bug reports, fed up newbies, many 'ruined' first-foss-contact chances ("uuuhh doesn't work on first try i'm going back to windows screw FOSS"). And I really don't think it is going to be of advantage to the code, too. ..more bug reports - what for? There's enough unfixed bugs, enough people involved hitting bugs, only too few people with the capability to fix them and i doubt calling wine 1.0 will attract more developers that are skilled enough to contribute code of a quality mr julliard is willing to commit.
So, we have to fix what we can and leave the rest until later. If you have a better plan, tell us. Relax the code freeze a bit and stay in RC phase for as many releases as the beta phase..? regards marcel.
On Mon, May 12, 2008 at 9:48 PM, Marcel Partap <mpartap(a)gmx.net> wrote:
Attracting users by promising a major step forward - a finished x.0 release - that don't already come to wine by other means may backfire - a zillion useless bug reports, fed up newbies, many 'ruined' first-foss-contact chances
We should make it very clear in each and every announcement we make that Wine 1.0 will NOT run most windows programs, and link to the list of 1000 apps it probably runs well. I've certainly tried to emphasize its limitations every time I open my mouth in public.
And I really don't think it is going to be of advantage to the code, too. ..more bug reports - what for? There's enough unfixed bugs, enough people involved hitting bugs, only too few people with the capability to fix them and i doubt calling wine 1.0 will attract more developers that are skilled enough to contribute code of a quality mr julliard is willing to commit.
There are probably lots of bugs in, say, Photoshop CS2 that I'd get fixed right quick if I knew about them, but not enough people are using it to know they're there. And even bug reports that sit around unfixed can end up useful when somebody finally takes an interest in a problem.
Relax the code freeze a bit and stay in RC phase for as many releases as the beta phase..?
That's like saying "don't do the 1.0 release yet, just keep doing 0.9.62, etc..." Not going to happen. Wine needs a release. All good open source projects need to release (not just make snapshots) periodically. Our last one was several years ago, and by doing a release, we are cleaning up a lot of bugs that have been lingering and annoying users for years. (Serial I/O, anyone? DOS apps?) - Dan
Relax the code freeze a bit and stay in RC phase for as many releases as the beta phase..?
That's like saying "don't do the 1.0 release yet, just keep doing 0.9.62, etc..." Not going to happen. Wine needs a release. All good open source projects need to release (not just make snapshots) periodically. Our last one was several years ago, and by doing a release, we are cleaning up a lot of bugs that have been lingering and annoying users for years. (Serial I/O, anyone? DOS apps?)
Sure, but doing a release on a unmovable schedule is also a mistake, imho; you want to release when you feel you have something of solid value. It should not be the case that a large block of conventional wisdom has it that 0.9.58 is 'better' than 1.0. Obvious and large blocks of regressions are a valid show stopper, again imho. But isn't this all just normal and expected? We had a big push by people to get features in prior to the freeze, so a lot of new features went in right before the freeze. Now we have to shake out the regressions and fix them. That process is a PITA, and usually takes a few weeks. Isn't that what we're doing? Cheers, Jeremy
participants (7)
-
Dan Kegel -
James Hawkins -
James McKenzie -
Jeremy White -
Marcel Partap -
Stefan Dösinger -
Vitaliy Margolen