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