On Fri, 12 May 2000, Patrik Stridvall wrote:
> > 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.
But would we (well, Alexandre) bother to do that kind of release cycle
during alpha? I suspect not.
(Since WineHQ (and thus the mailing list) is down right now, we'll have to
wait a little for an answer to that...)
> > 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?
Nothing, that had to do with you claiming that the model of stable vs
development trees not being applicable to Wine.
> > 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.
I have no experience with BitKeeper (the formal way of saying: don't know
a thing about it).
> > 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.
But that would rule out the automatic merging of the release branch back
into the main branch after the release, and we'd have a maintenance
problem again...
> 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'm not entirely sure what you mean here.
> > 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?
I tried to clean it once, but didn't get halfway... so not me this time at
least, I won't have time.
And I still hope we can get more stability to WineHQ and mirrors before we
put out public releases, now that the mail server was down again...
