On Fri, 12 May 2000, Patrik Stridvall wrote:
> > Given the amount of progress Wine has made over the past year,
> > it seems (to me anyway) that the time may be appropriate to
> > try for Wine version 1.0.
>
> Perhaps, but personally I see Wine version 1.0 more
> like a marketing gimmick, not something that has
> large technical advantages for users or developers.
Yes it does - the release process would be more geared towards stability
and quality assurance, something currently rather unheard of (no offense
to Alexandre, I just mean that no release I know of has had a formal
testing period between applying the latest patches and putting out the
release).
> Of course that doesn't mean that we shouldn't do it.
But I think Wine should enter beta first, not go directly to 1.0.
> First of all Wine is not normal project. In normal projects
> the conflict between more features and stabillity is very
> mportant, so they usually have two trees stable and development.
>
> In Wine, this issue is not at all that important.
> Since the API:s are specified by Microsoft the
> most work are not spend on inventing new features,
> but rather on fixing bugs. Note that by bugs I also
> mean implementations of previously not implemented
> functions. Since they wasn't implemented they
> didn't satisfy the documentation, and thus they
> were buggy.
I think you're forgetting something - over half of the releases the last
year was released at such a point that one patch made the difference
between Wine working and not working for a very large group of users (this
is know as showstoppers). With just a few days of code freeze in the
stable tree before the release, almost all of these could have been
avoided.
This is so because most more-than-one-line bug fixes (and even many of the
one-liners!) or feature implementations rewrites or changes some behaviour
in Wine, which easily break other dependent parts of Wine. And it goes
without saying that big structural changes can be even harder to get right
immediately without ill effects. And often, a release happened to be made
right after applying one such...
With alpha status, we have an excuse for that, but this can't go on if
we're going to beta and 1.0. We need release cycles with code freezes and
such, the freeze just doesn't have to be that long, a week should suffice
for most purposes.
> With that in mind most developers are not implementing
> new feature and thus most fixes, with the exception
> optmizations, should, if we have two trees, be applied to
> both of them.
>
> This makes having two trees less meaningful and creates
> a huge adminstrative problem, especially if large
> reorganizations are made in the developments tree.
No, we use two CVS *branches*. If parallel development is desirable, it is
possible (and not too uncommon) to follow a procedure like this:
1. Development goes on in the main branch
2. When we want to start a release (code freeze), we tag the main branch
and create a CVS branch from there
3. Simple or critical bug fixes go into the release branch, everything
else (implementations that can potentially break something) go into the
main branch
4. Whenever the release branch is thought of as ready for prime time, it
is released to the public
6. The release branch is then merged/folded back into the development
branch (CVS can do this automatically), thus any leftover bugfixes in the
release branch are guaranteed to go into the main branch at this point
7. Go back to 1
It is also possible to fork the branch the other way (the release branch
is the main branch, and the development branch is the new branch for the
duration of the freeze), if that is more convenient. What the policy would
be would only be important if there are a lot of people with CVS commit
access, which we don't have.
Of course, Alexandre could assign someone as "release manager" to commit
the simple/critical bug fixes to the release tree, while he keeps on
working on the main branch himself...
I think that even if the code freeze is no more than one week, such a
freeze would be a big benefit to users, because it would avoid all the
showstoppers that have plagued almost every Wine release.
> > 2. What needs to be done before we can release Wine 1.0?
>
> The most important one is address space separation.
>
> Secondly we need to assure that all non-core dlls
> doesn't access things outside each dll except through
> standardized mechanisms. I think most problems of
> these kind are fixed, but it is important that
> all of them are fixed since it will allow us
> to develop and test the core dlls separate from
> the non-core ones.
In other words, the elf-dlls?
Perhaps we should at least have someone that actually bothers to read and
clean up the bug database, too (we could call him QA).
And perhaps we should get WineHQ mirroring working.
There are also some window management issues I'd like to see sorted out.
(For example, with most window managers, it is possible to create a
managed but completely undecorated window, just look at XMMS - we should
have an option to create those instead of completely unmanaged windows).
