Re: [libvirt] Plan for next release(s)
On Dec 1, 2016 6:12 AM, "Andrea Bolognani"wrote: > > On Mon, 2016-11-28 at 21:53 -0500, Laine Stump wrote: > > P.S. to Andrea - I will write a NEWS file entry, but I guess that can be > > safely pushed after Daniel freezes :-) > > You better! ;) Posted last night. I'm not sure if it's too verbose. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Plan for next release(s)
On Mon, 2016-11-28 at 21:53 -0500, Laine Stump wrote: [...] > it was too late in > the day to have a discussion with him about his question here: > > https://www.redhat.com/archives/libvir-list/2016-November/msg01204.html > > He didn't give a NACK for putting that function in now (rather than > using stat() directly), but also didn't give an ACK. I did neither ACK nor NACK because I was wondering if the approach you took, which is completely fine as far as the specific functionality you are implementing is concerned (should have stressed this fact more in my reply), was the best one going forward, and wanted to discuss that with you. What I failed to take into account is the fact that *you* were on your PTO and, by the time you got back, *I* would be on mine :( But I see Eric helpfully jumped in and provided more positive feedback that, along with my lack of NACK, convinced you to push. That's great! We can discuss about this more in due time, but there was really no reason to leave this feature out of the release for what is just an implementation detail. [...] > P.S. to Andrea - I will write a NEWS file entry, but I guess that can be > safely pushed after Daniel freezes :-) You better! ;) -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Plan for next release(s)
Planning the release before flying, i.e. before you can do anything my bad I was late. Patches 1 and 2 can't seem to be able to introduce regressions. The meat is really into patches 3 and 4. if you and others feel confident about those 2 then have the series pushed between rc1 and rc2, that still gives a bit of time for testing. And in worse case if this w.e. we still have an issue pending we can delay onto next week for the final 2.5.0, so go with plan :-) Daniel On Mon, Nov 28, 2016 at 09:53:20PM -0500, Laine Stump wrote: > On 11/28/2016 03:06 PM, Daniel Veillard wrote: > > I'm late so I think that if we don't want to slip too much > > the best would be to enter freeze tomorrow (Tuesday) then have RC2 > > around Thursday and a release over the week-end. > > Are you saying you want to freeze tomorrow *morning* your time (ie. before > they "mess with" your internet), or tomorrow *afternoon* (when it will of > course be working properly again)? > > I had hoped to push the series "qemu: assign vfio devices to PCIe addresses > when appropriate" for this release, > > https://www.redhat.com/archives/libvir-list/2016-November/msg00964.html > > but by the time I got back from the long Thanksgiving holiday and caught up > enough with my email to get to Andrea's reviews, it was too late in the day > to have a discussion with him about his question here: > > https://www.redhat.com/archives/libvir-list/2016-November/msg01204.html > > He didn't give a NACK for putting that function in now (rather than using > stat() directly), but also didn't give an ACK. My opinion is in my response: > > https://www.redhat.com/archives/libvir-list/2016-November/msg01402.html > > in short, I would rather add the (simple) new function now to promote its > use, anticipating that it will be expanded as necessary when it is used in > more places. > > As long as this is okay and that patch can be ACKed, I have the minor > modifications for the other 3 patches ready to go and can push with a few > moments' notice. > > As usual, don't screw up your schedule just to accomodate me, but if you can > try pinging me on IRC prior to freezing (just in case I'm awake and I've > gotten a response about that patch and can push), that would be appreciated > (do go ahead and freeze if I don't respond) > > P.S. to Andrea - I will write a NEWS file entry, but I guess that can be > safely pushed after Daniel freezes :-) > > > > > That said they are supposed to mess with my internet tomorrow morning > > and I'm travelling till the end of the week, but the above plan should > > be doable. Hope that's okay with everybody. > > > > Then usually December is a low productivity month, and Feb is short, > > so it is tempting to do like for previous years i.e. release mid-january > > and end of Feb, except the Jan release will be 3.0.0. > > > > Works for everybody ? > > > > Daniel > > -- Daniel Veillard | Open Source and Standards, Red Hat veill...@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Plan for next release(s)
On Mon, Nov 28, 2016 at 09:06:41PM +0100, Daniel Veillard wrote: > I'm late so I think that if we don't want to slip too much > the best would be to enter freeze tomorrow (Tuesday) then have RC2 > around Thursday and a release over the week-end. > > That said they are supposed to mess with my internet tomorrow morning > and I'm travelling till the end of the week, but the above plan should > be doable. Hope that's okay with everybody. > > Then usually December is a low productivity month, and Feb is short, > so it is tempting to do like for previous years i.e. release mid-january > and end of Feb, except the Jan release will be 3.0.0. > >Works for everybody ? Yes, that matches our documented release schedule :-) "releases made once a month on the 1st of each month give or take a few days. The only exception is at the start of the year where there are two 6 weeks gaps (first release in the middle of Jan, then skip the Feb release), giving a total of 11 releases a year." http://libvirt.org/downloads.html#schedule Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o-http://search.cpan.org/~danberr/ :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Plan for next release(s)
On 11/28/2016 03:06 PM, Daniel Veillard wrote: I'm late so I think that if we don't want to slip too much the best would be to enter freeze tomorrow (Tuesday) then have RC2 around Thursday and a release over the week-end. Are you saying you want to freeze tomorrow *morning* your time (ie. before they "mess with" your internet), or tomorrow *afternoon* (when it will of course be working properly again)? I had hoped to push the series "qemu: assign vfio devices to PCIe addresses when appropriate" for this release, https://www.redhat.com/archives/libvir-list/2016-November/msg00964.html but by the time I got back from the long Thanksgiving holiday and caught up enough with my email to get to Andrea's reviews, it was too late in the day to have a discussion with him about his question here: https://www.redhat.com/archives/libvir-list/2016-November/msg01204.html He didn't give a NACK for putting that function in now (rather than using stat() directly), but also didn't give an ACK. My opinion is in my response: https://www.redhat.com/archives/libvir-list/2016-November/msg01402.html in short, I would rather add the (simple) new function now to promote its use, anticipating that it will be expanded as necessary when it is used in more places. As long as this is okay and that patch can be ACKed, I have the minor modifications for the other 3 patches ready to go and can push with a few moments' notice. As usual, don't screw up your schedule just to accomodate me, but if you can try pinging me on IRC prior to freezing (just in case I'm awake and I've gotten a response about that patch and can push), that would be appreciated (do go ahead and freeze if I don't respond) P.S. to Andrea - I will write a NEWS file entry, but I guess that can be safely pushed after Daniel freezes :-) That said they are supposed to mess with my internet tomorrow morning and I'm travelling till the end of the week, but the above plan should be doable. Hope that's okay with everybody. Then usually December is a low productivity month, and Feb is short, so it is tempting to do like for previous years i.e. release mid-january and end of Feb, except the Jan release will be 3.0.0. Works for everybody ? Daniel -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list