From: Sam Trenholme (abiword_bugs@yahoo.com)
Date: Fri Apr 26 2002 - 05:09:23 EDT
> I only see one problem with this: we do not have
> anyone willing to take
> on the job as QA+Release Engineering who is able to
> spend time on
> putting a release candidate through its paces and
> ask developers to fix
> problems found. If this is should have any chance of
> happening in a
> timely fashion, we need someone dedicated to the
> task.
I don't think a formal QA/Release cycle is needed
here; we can take advantage of the bazaar model
big-time here.
What I am envisioning is something like this:
* Warn the developers three or four days in advanced
that a new branch will be made; ideally giving an
exact date and time (Like what happened with the 1.0.0
release)
* At the "freeze" time, make a new CVS branch, calling
it, say, "1.2.6rc1" (Can CVS handle that kind of
version name?)
* CVS frozen on new branch for a day or so; developers
and CVSers [1] can look at the code for nasty bugs.
* RC branch is tagged. Tarballs, RPMS, and what not
are made.
* RC branch is released out to the big bad world.
* People in said big bad world report bugs on the RC
branch. This should only take a week or so.
* Serious bugs (crashes, functionality broken and
easily fixed, etc.) are fixed. Most bugs are
deferred; this is mainly to fix things caused by last
minute oversight.
* Release rc2 with said bugs fixed is released about a
week later.
* If nothing serious (and easily fixed) shows up for a
day or two after rc2, make it official.
We don't need anything like a QA team and a room full
of slaves doing regression by hand to make this kind
of release schedule a reality.
Does this sound like something that is easily done?
Or am I missing some complication that this kind of
release schedule would cause?
- Sam
_________________________________________________________
Do You Yahoo!?
La emoción e intensidad del deporte en Yahoo! Deportes. http://deportes.yahoo.com.mx
This archive was generated by hypermail 2.1.4 : Fri Apr 26 2002 - 05:11:36 EDT