On Mon, May 5, 2008 at 6:54 AM, Alexandre Julliard <[EMAIL PROTECTED]> wrote: > It's the distro that changed the mmap config, not the kernel. I'm not > sure I understand their reasoning, apparently this was an attempt to > work around the vulnerability without fixing the kernel.
Oh, right. I think they were using belt and suspenders, on the theory that more such bugs may be lurking. > My point is that if they cared about Wine they would have taken > into account the fact that it got broken, and hopefully found a different > way of addressing the issue. Indeed, they don't care about Wine enough yet. I suspect that this will change once enough of the latest Adobe apps run. > Of all the breakages we've had over the years very > few were caused by the kernel; most were caused by distros shipping > unstable and untested packages, or broken default configs. I stand corrected. > Making a stable release is a lot of work, particularly since given the > nature of Wine it's very hard to test it properly and make sure we are > not breaking things. The QA argument is a good one. I would not feel comfortable doing quick releases until we had a better automated app QA story -- even though automated app QA never finds many bugs, it would provide some insurance against brown-paper-bag regressions. We would also need a fairly large army of early adopters willing to try release candidates. > We don't want to go through the process unless we > have some significant features to release, and significant features > can't be developed on a fixed time frame. > For instance, one feature we'd want in 1.2 is the DIB engine; nobody can > guarantee that it will be ready, tested, and debugged properly by > September. I'd much prefer to ship 1.2 with a working DIB engine say in > December, than with a broken one in September. There are other features we might want in 1.2, for instance, Photoshop CS3 support. But I would happily ship a 1.2 that had none of these features if it contained significant bugfixes, or if it had only CS3 support and not a DIB Engine, or vice versa. - Dan
