On Mon, May 12, 2008 at 10:52 PM, James McKenzie jjmckenzie51@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.