> 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
