> 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.
Probably not, but we might start to do that when we declare Wine a beta.
In any case when we declared Wine a beta we much do something about
the quality of the releases.
> (Since WineHQ (and thus the mailing list) is down right now,
> we'll have to
> wait a little for an answer to that...)
Yes. I wonder what happend. I guess you too got Alexandre's
and later Bertho's reply to the "Fixed byte order on Solaris
and FreeBSD" thread. When I was working on fixing the problem,
the CVS (commit.winehq.com) was _very_ slow, eventhough it worked.
After succeding (slow!!!) with "cvs diff", the patch never got
to the list so it must have broken down about 01.00 (GMT+1).
> > > 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.
What I meant was that, having seperate trees like most other
projects have is not applicable to Wine. I never denied
that the stable vs development problem existed, just
that we need to solve this problem in a different way.
> > > 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).
Neither have I, but I have read about it (http://www.bitkeeper.com).
Some intresting features that CVS lacks like renaming support
and Lines of Development could be more useful to us
that to most other project, because we, as I said,
can't solve the stable vs development problem in
the same way as them.
The drawback is that it is under a non free license,
use for Open Source projects is free though.
> > > 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...
Unless Alexandre _is_ the release mangager that problem will
still exist, in fact even _with_ Alexandre as release manager
he will probably in some cases accept patches in the release
branch that he will reject for the development branch.
Eventhough automatic merging will not work, the release
branch is supposed to be small so I don't think that will be
a large problem.
There should be few reasons to apply a patch to the release branch
* It fixes a _reported_ problem
* It fixes a _serious_ potential problem
If a patch doesn't statisfy these criteria,
it shouldn't be applied to the relase branch at all.
> > 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.
Sorry, I should have formulated that better.
What I mean is that as long as Wine is alpha it is
less meaningful to use your solution, so using your
solution, if we decide to do so, will have to wait
until Wine is declared beta.
> 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...
Yes, this is starting to get irritating.
