On Thu, Dec 02, 2010 at 05:47:01AM +1100, Justin Clift wrote:
On 02/12/2010, at 5:26 AM, Diego Elio Pettenò wrote:
Il giorno gio, 02/12/2010 alle 02.47 +1100, Justin Clift ha scritto:
Looks like it might be time to put some kind of regression testing in place, as a go/no-go release criteria.
May I suggest a 1-week (or less) window without merge of new features/improvements, announced on a separate (low-traffic) mailinglist for packagers to test the release?
We'd then have time to test whether the code is fine for all of us or not.
Concept wise, do you reckon something like this would work:
+ a new libvirt-announce mailing list, low trafic, purely for release announcements and similar
Along with us announcing a '"release candidate" build through it (instead of the present approach). If it looks good after a period of time (a week or something as you mentioned), then it gets re-released as the actual release.
If something turns up significantly broken, then we respin as a release candidate 2 and repeat the process.
I think this is really viable, because it implies we need another week prior to creating the pre-release where we do what we currently do with pre-release stabalization. With a monthly release cycle, taking 2 weeks todo a release is too much of an time sink. IMHO, we need to have - A official list of supported platforms / OS combinations - Run a test build on each combination before release - Actually follow the 'bug fixes' only rule leading upto release no matter how simple the new feature might appear. Daniel