> From: "Bill Stoddard" <[EMAIL PROTECTED]>
> Sent: Thursday, August 30, 2001 11:55 AM
>
>
> > Not really. The process Cliff and I outlined is really aimed at getting -a- stable
release
> > available. The process will take at least 2 days to go through but shouldn't take
>more
> > than maybe 4 days total. If we use this process AND use your suggestions to not
>commit
> > huge chunks of untested code during our 'stabilization period' I am confident we
>can
get
> > stable releases out on almost every try. We can control the release of tarballs to
>the
> > test community.
> >
> > And what is the point of having testers spend time on a release that we know is
broken?
> > Isn't it better to just tell them "hey don't waste your time on this tarball"?.
OTOH...
> > what rule says that testers must test each and every tarball? If a tarball (even an
alpha
> > tarball) works well enough, the testers can still find and report bugs that we
>havent
> > discovered yet.
> >
> > One other question... have you received complaints from testers about the
>frequencey
of
> > our tarball updates?
>
> Keep in mind one key detail, our most _active_ testers are using cvs (even on win32
>;)
>
>
>
> > I don't think we are currently using the model suggested by Roy. I believe Roy's
>model
is
> > closer to what Cliff and I are advocating. With one exception... The exception is
>that
> > some of us believe a 'feature freeze' (or 'big code change freeze', whatever you
>want
to
> > call it) needs to go into effect during the 'stabilizing period'. I know Roy
>doesn't
like
> > this idea but I see no other way out of our current inability to get stable
>releases.
>
> There is no such need. Tag. Roll in or out the changes that get a particular
>version
> stable. We have CVS. Use it.
>
>
>
> > > Yep. :-) But we also need to stop committing every possible change immediately.
> >
> > +1. Announce when we are in the 'stabilization period' and discourage (prohibit?
>:-)
big
> > commits during the period that do not enhance stability.
>
> My other post suggests we simply follow R-T-C (with a strict 3 +1's except on obscure
> build maintenance by platform maintainers) on a tagged branch. There's no need for
>this
> in the main tree.
>
> See my post to rbb for the rest of my thoughts on this personal slight,
> you are certainly impliciated as well.
>
No slight intended, personal or otherwise. Big code drops going in right as we
announce a
tag & roll is normal. It happens -every- time and most of us have been the perps at one
time or another. This is pretty normal in closed source development shops as well when
trying to hit driver dates. Everybody has code that -must- go in or the release will
just
be totally hosed (in their mind :-).
We clearly have a problem getting stable releases out and I'm interested in solving the
problem, not pointing fingers.
Bill