Daniel P. Berrange wrote: >> >> 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. > Perhaps a 24 hour release candidate period? I have a staging project in openSUSE Build Service that builds for all currently supported SuSE products, which is a wide range of capabilities wrt Policy Kit versions, hal vs udev, libnl, avahi versions, cap-ng, netcf, macvtap, virtualport, yajl, ... I can deploy a release candidate tarball to the libvirt package in this project quickly to test building across these various SuSE products. I suspect there is an opportunity for some automation here as well. Regards, Jim -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list