4:53 a.m.
Happy New Year everybody,
as planned we should release 5.0.0 around Jan 15. This means that
the best to meet that deadline would be to enter freeze tomorrow Thur,
then have an RC2 over the w.e. and then if all goes well we can roll
out the release next Tuesday.
If there is no issue with this plan I will then release RC1 tomorrow
probably in the evening european time,
thanks,
Daniel
--
Daniel Veillard | Red Hat Developers Tools http://developer.redhat.com/
veillard(a)redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | virtualization library http://libvirt.org/
11:03 a.m.
On 1/9/19 3:53 PM, Daniel Veillard wrote:
Happy New Year everybody,
as planned we should release 5.0.0 around Jan 15. This means that
the best to meet that deadline would be to enter freeze tomorrow Thur,
then have an RC2 over the w.e. and then if all goes well we can roll
out the release next Tuesday.
If there is no issue with this plan I will then release RC1 tomorrow
probably in the evening european time,
Because it creates a change in behavior that will be easier to deal with
at a major release number (and because I want to backport the patches as
soon as possible, and likely whoever is working on the next release of
debian will as well, since they have the same problem!) I would really
like to get these patches in before you freeze:
https://www.redhat.com/archives/libvir-list/2019-January/msg00227.html
<https://www.redhat.com/archives/libvir-list/2019-January/msg00227.html>
Likewise, it would be good to get these in, since they are fixing a bonafide crash:
https://www.redhat.com/archives/libvir-list/2019-January/msg00204.html
6:08 p.m.
On Wed, Jan 09, 2019 at 10:03:33PM -0500, Laine Stump wrote:
On 1/9/19 3:53 PM, Daniel Veillard wrote:
> Happy New Year everybody,
>
> as planned we should release 5.0.0 around Jan 15. This means that
> the best to meet that deadline would be to enter freeze tomorrow Thur,
> then have an RC2 over the w.e. and then if all goes well we can roll
> out the release next Tuesday.
>
> If there is no issue with this plan I will then release RC1 tomorrow
> probably in the evening european time,
Because it creates a change in behavior that will be easier to deal with at
a major release number (and because I want to backport the patches as soon
as possible, and likely whoever is working on the next release of debian
will as well, since they have the same problem!) I would really like to get
these patches in before you freeze:
There is /no/ functional meaning to libvirt major release numbers, so
from that POV, major changes like are expected in any release. IOW there
is no reason to rush into 5.0.0 unless they do indeed satisfy normal
review.
https://www.redhat.com/archives/libvir-list/2019-January/msg00227.html
<https://www.redhat.com/archives/libvir-list/2019-January/msg00227.html>
Likewise, it would be good to get these in, since they are fixing a bonafide crash:
https://www.redhat.com/archives/libvir-list/2019-January/msg00204.html
--
libvir-list mailing list
libvir-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
9:31 p.m.
On 1/10/19 5:08 AM, Daniel P. Berrangé wrote:
On Wed, Jan 09, 2019 at 10:03:33PM -0500, Laine Stump wrote:
> On 1/9/19 3:53 PM, Daniel Veillard wrote:
>> Happy New Year everybody,
>>
>> as planned we should release 5.0.0 around Jan 15. This means that
>> the best to meet that deadline would be to enter freeze tomorrow Thur,
>> then have an RC2 over the w.e. and then if all goes well we can roll
>> out the release next Tuesday.
>>
>> If there is no issue with this plan I will then release RC1 tomorrow
>> probably in the evening european time,
>
> Because it creates a change in behavior that will be easier to deal with at
> a major release number (and because I want to backport the patches as soon
> as possible, and likely whoever is working on the next release of debian
> will as well, since they have the same problem!) I would really like to get
> these patches in before you freeze:
There is /no/ functional meaning to libvirt major release numbers, so
from that POV, major changes like are expected in any release.
Yeah, my brain knows that but it just feels like a better story if a
change in behavior happens at a release that has a lot of zeros in it :-)
IOW there
is no reason to rush into 5.0.0 unless they do indeed satisfy normal
review.
And actually thinking about it more, it would probably be better to find
somebody who's running debian new enough to have an nftables backend and
can test those patches before I push them, rather than rushing in
something that may only work for me. (And after all, the next release
will still have a .0 at the end!)
> https://www.redhat.com/archives/libvir-list/2019-January/msg00227.html
<https://www.redhat.com/archives/libvir-list/2019-January/msg00227.html>
>
>
> Likewise, it would be good to get these in, since they are fixing a bonafide crash:
>
>
> https://www.redhat.com/archives/libvir-list/2019-January/msg00204.html
These would still be nice to get in, though.
2108
days inactive
2109
days old
3 comments
3 participants
participants (3)
-
Daniel P. Berrangé -
Daniel Veillard -
Laine Stump