Re: [libvirt] Plan for next release(s)

2016-12-01 Thread Laine Stump
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)

2016-12-01 Thread Andrea Bolognani
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)

2016-11-29 Thread Daniel Veillard
  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)

2016-11-29 Thread Daniel P. Berrange
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)

2016-11-28 Thread Laine Stump

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