Time-based releases idea

[Dan Kegel]

On Mon, May 5, 2008 at 6:54 AM, Alexandre Julliard <julliard at winehq.org> 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