> 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).
Sure but the point is that the release process in itself has
not much to do with Wine version 1.0, we could do that even now.
> > 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.
Agreed.
> > 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 -
I am quite aware of that, I have not forgotten.
> 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.
Sure but that was that to do with Wine 1.0?
We could do that for each release even now.
> 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...
Agreed.
> 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.
Agreed.
> > 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:
[procedure sniped]
Excellent idea.
As a related question, perhaps we should discuss using
BitKeeper instead of CVS then Wine 1.0 is released.
I suggest we continue using CVS during the beta testing,
while we discuss whether we should use BitKeeper
after Wine 1.0 is released.
> 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...
Perhaps we even should allow anybody who is _qualified_
apply patches to the release branch. If something
is severly broken, a kludgy fix is better than no fix.
It speeds up the process quite a lot since everybody that is
intrested can test the fix right away with waiting
for the release manager to apply it.
After all Alexandre can reject the changes for the main
tree if he so wishes.
I suggest that if we decide to use your (Ove's) suggestion,
we offical declare Wine a beta when we branch the CVS
for each public relase.
> 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.
Agreed.
> > > 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?
In principle yes. The important thing is that we can,
if we have two tree, use the new non-core dlls with
the old core dlls. But perhaps we don't need two
trees. We can, as you pointed out, use CVS branches
instead.
> Perhaps we should at least have someone that actually bothers
> to read and
> clean up the bug database, too (we could call him QA).
Yes. Volunters?
