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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list