* Rusty away 18th September -- 11th October @ 2014-09-11 0:56 ` Rusty Russell 0 siblings, 0 replies; 14+ messages in thread From: Rusty Russell @ 2014-09-11 0:56 UTC (permalink / raw) To: Linus Torvalds; +Cc: LKML, virtualization, netdev, Michael S. Tsirkin Hi all, Probably won't read mail. Linus, I'll have pull requests early next week; if there's anything needed I'm sure Michael Tsirkin can handle it. Cheers, Rusty. PS. England and Italy for a holiday; my daughter chose them (somehow I forgot to inform her of the existence of Euro Disney...) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Rusty away 18th September -- 11th October @ 2014-09-11 0:56 ` Rusty Russell 0 siblings, 0 replies; 14+ messages in thread From: Rusty Russell @ 2014-09-11 0:56 UTC (permalink / raw) To: Linus Torvalds; +Cc: netdev, Michael S. Tsirkin, LKML, virtualization Hi all, Probably won't read mail. Linus, I'll have pull requests early next week; if there's anything needed I'm sure Michael Tsirkin can handle it. Cheers, Rusty. PS. England and Italy for a holiday; my daughter chose them (somehow I forgot to inform her of the existence of Euro Disney...) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Rusty away 18th September -- 11th October 2014-09-11 0:56 ` Rusty Russell @ 2014-09-11 11:43 ` Michael S. Tsirkin -1 siblings, 0 replies; 14+ messages in thread From: Michael S. Tsirkin @ 2014-09-11 11:43 UTC (permalink / raw) To: Rusty Russell; +Cc: Linus Torvalds, LKML, virtualization, netdev On Thu, Sep 11, 2014 at 10:26:52AM +0930, Rusty Russell wrote: > Hi all, > > Probably won't read mail. Linus, I'll have pull requests early > next week; if there's anything needed I'm sure Michael Tsirkin can > handle it. Sure. Rusty, there's a small chance virtio 1.0 bits will be ready in time. I started working on them based on your virtio-pci-new-layout branch. If ready before the merge window, are you ok with me merging this support (without you having the opportunity to review first)? -- MST ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Rusty away 18th September -- 11th October @ 2014-09-11 11:43 ` Michael S. Tsirkin 0 siblings, 0 replies; 14+ messages in thread From: Michael S. Tsirkin @ 2014-09-11 11:43 UTC (permalink / raw) To: Rusty Russell; +Cc: netdev, Linus Torvalds, LKML, virtualization On Thu, Sep 11, 2014 at 10:26:52AM +0930, Rusty Russell wrote: > Hi all, > > Probably won't read mail. Linus, I'll have pull requests early > next week; if there's anything needed I'm sure Michael Tsirkin can > handle it. Sure. Rusty, there's a small chance virtio 1.0 bits will be ready in time. I started working on them based on your virtio-pci-new-layout branch. If ready before the merge window, are you ok with me merging this support (without you having the opportunity to review first)? -- MST ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Rusty away 18th September -- 11th October 2014-09-11 11:43 ` Michael S. Tsirkin @ 2014-09-12 1:28 ` Rusty Russell -1 siblings, 0 replies; 14+ messages in thread From: Rusty Russell @ 2014-09-12 1:28 UTC (permalink / raw) To: Michael S. Tsirkin; +Cc: Linus Torvalds, LKML, virtualization, netdev "Michael S. Tsirkin" <mst@redhat.com> writes: > On Thu, Sep 11, 2014 at 10:26:52AM +0930, Rusty Russell wrote: >> Hi all, >> >> Probably won't read mail. Linus, I'll have pull requests early >> next week; if there's anything needed I'm sure Michael Tsirkin can >> handle it. > > Sure. > Rusty, there's a small chance virtio 1.0 bits will be ready in time. > I started working on them based on your virtio-pci-new-layout branch. > > If ready before the merge window, are you ok with me merging this > support (without you having the opportunity to review first)? Sorry, absolutely not. I *really* want to review this in depth; if we make a mistake, it's going to hurt us significantly. And until we have the qemu bits ready, it's really hard to tell if we've got this right. So I'd rather delay and make sure we're solid. Thanks, Rusty. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Rusty away 18th September -- 11th October @ 2014-09-12 1:28 ` Rusty Russell 0 siblings, 0 replies; 14+ messages in thread From: Rusty Russell @ 2014-09-12 1:28 UTC (permalink / raw) To: Michael S. Tsirkin; +Cc: netdev, Linus Torvalds, LKML, virtualization "Michael S. Tsirkin" <mst@redhat.com> writes: > On Thu, Sep 11, 2014 at 10:26:52AM +0930, Rusty Russell wrote: >> Hi all, >> >> Probably won't read mail. Linus, I'll have pull requests early >> next week; if there's anything needed I'm sure Michael Tsirkin can >> handle it. > > Sure. > Rusty, there's a small chance virtio 1.0 bits will be ready in time. > I started working on them based on your virtio-pci-new-layout branch. > > If ready before the merge window, are you ok with me merging this > support (without you having the opportunity to review first)? Sorry, absolutely not. I *really* want to review this in depth; if we make a mistake, it's going to hurt us significantly. And until we have the qemu bits ready, it's really hard to tell if we've got this right. So I'd rather delay and make sure we're solid. Thanks, Rusty. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Rusty away 18th September -- 11th October 2014-09-12 1:28 ` Rusty Russell @ 2014-09-14 6:21 ` Michael S. Tsirkin -1 siblings, 0 replies; 14+ messages in thread From: Michael S. Tsirkin @ 2014-09-14 6:21 UTC (permalink / raw) To: Rusty Russell; +Cc: Linus Torvalds, LKML, virtualization, netdev On Fri, Sep 12, 2014 at 10:58:03AM +0930, Rusty Russell wrote: > "Michael S. Tsirkin" <mst@redhat.com> writes: > > On Thu, Sep 11, 2014 at 10:26:52AM +0930, Rusty Russell wrote: > >> Hi all, > >> > >> Probably won't read mail. Linus, I'll have pull requests early > >> next week; if there's anything needed I'm sure Michael Tsirkin can > >> handle it. > > > > Sure. > > Rusty, there's a small chance virtio 1.0 bits will be ready in time. > > I started working on them based on your virtio-pci-new-layout branch. > > > > If ready before the merge window, are you ok with me merging this > > support (without you having the opportunity to review first)? > > Sorry, absolutely not. I *really* want to review this in depth; if we > make a mistake, it's going to hurt us significantly. Right but it's only a merge window - we can fix bugs and even disable the new driver afterwards, can't we? > And until we have the qemu bits ready, it's really hard to tell if we've > got this right. Sure, I meant if qemu bits are ready too, and if things work together. It wouldn't do to merge a driver that isn't ready. > So I'd rather delay and make sure we're solid. > > Thanks, > Rusty. Something else we can do, is refactoring that splits driver out to common and legacy bits, and changes APIs. No? -- MSt ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Rusty away 18th September -- 11th October @ 2014-09-14 6:21 ` Michael S. Tsirkin 0 siblings, 0 replies; 14+ messages in thread From: Michael S. Tsirkin @ 2014-09-14 6:21 UTC (permalink / raw) To: Rusty Russell; +Cc: netdev, Linus Torvalds, LKML, virtualization On Fri, Sep 12, 2014 at 10:58:03AM +0930, Rusty Russell wrote: > "Michael S. Tsirkin" <mst@redhat.com> writes: > > On Thu, Sep 11, 2014 at 10:26:52AM +0930, Rusty Russell wrote: > >> Hi all, > >> > >> Probably won't read mail. Linus, I'll have pull requests early > >> next week; if there's anything needed I'm sure Michael Tsirkin can > >> handle it. > > > > Sure. > > Rusty, there's a small chance virtio 1.0 bits will be ready in time. > > I started working on them based on your virtio-pci-new-layout branch. > > > > If ready before the merge window, are you ok with me merging this > > support (without you having the opportunity to review first)? > > Sorry, absolutely not. I *really* want to review this in depth; if we > make a mistake, it's going to hurt us significantly. Right but it's only a merge window - we can fix bugs and even disable the new driver afterwards, can't we? > And until we have the qemu bits ready, it's really hard to tell if we've > got this right. Sure, I meant if qemu bits are ready too, and if things work together. It wouldn't do to merge a driver that isn't ready. > So I'd rather delay and make sure we're solid. > > Thanks, > Rusty. Something else we can do, is refactoring that splits driver out to common and legacy bits, and changes APIs. No? -- MSt ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Rusty away 18th September -- 11th October 2014-09-14 6:21 ` Michael S. Tsirkin @ 2014-09-16 15:53 ` Rusty Russell -1 siblings, 0 replies; 14+ messages in thread From: Rusty Russell @ 2014-09-16 15:53 UTC (permalink / raw) To: Michael S. Tsirkin; +Cc: Linus Torvalds, LKML, virtualization, netdev "Michael S. Tsirkin" <mst@redhat.com> writes: > On Fri, Sep 12, 2014 at 10:58:03AM +0930, Rusty Russell wrote: >> "Michael S. Tsirkin" <mst@redhat.com> writes: >> > On Thu, Sep 11, 2014 at 10:26:52AM +0930, Rusty Russell wrote: >> >> Hi all, >> >> >> >> Probably won't read mail. Linus, I'll have pull requests early >> >> next week; if there's anything needed I'm sure Michael Tsirkin can >> >> handle it. >> > >> > Sure. >> > Rusty, there's a small chance virtio 1.0 bits will be ready in time. >> > I started working on them based on your virtio-pci-new-layout branch. >> > >> > If ready before the merge window, are you ok with me merging this >> > support (without you having the opportunity to review first)? >> >> Sorry, absolutely not. I *really* want to review this in depth; if we >> make a mistake, it's going to hurt us significantly. > > Right but it's only a merge window - we can fix bugs and even disable > the new driver afterwards, can't we? Yes, but if we get something wrong we have to live with it. We made that mistake with virtio-pci the first time around... It isn't enough that the code 'works', it has to match the spec. And that requires careful thought and review. >> And until we have the qemu bits ready, it's really hard to tell if we've >> got this right. > > Sure, I meant if qemu bits are ready too, and if things work together. > It wouldn't do to merge a driver that isn't ready. > > >> So I'd rather delay and make sure we're solid. >> >> Thanks, >> Rusty. > > Something else we can do, is refactoring that splits driver > out to common and legacy bits, and changes APIs. > No? Yes, for sure. But there's no hurry to get those into the merge window. Cheers, Rusty. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Rusty away 18th September -- 11th October @ 2014-09-16 15:53 ` Rusty Russell 0 siblings, 0 replies; 14+ messages in thread From: Rusty Russell @ 2014-09-16 15:53 UTC (permalink / raw) To: Michael S. Tsirkin; +Cc: netdev, Linus Torvalds, LKML, virtualization "Michael S. Tsirkin" <mst@redhat.com> writes: > On Fri, Sep 12, 2014 at 10:58:03AM +0930, Rusty Russell wrote: >> "Michael S. Tsirkin" <mst@redhat.com> writes: >> > On Thu, Sep 11, 2014 at 10:26:52AM +0930, Rusty Russell wrote: >> >> Hi all, >> >> >> >> Probably won't read mail. Linus, I'll have pull requests early >> >> next week; if there's anything needed I'm sure Michael Tsirkin can >> >> handle it. >> > >> > Sure. >> > Rusty, there's a small chance virtio 1.0 bits will be ready in time. >> > I started working on them based on your virtio-pci-new-layout branch. >> > >> > If ready before the merge window, are you ok with me merging this >> > support (without you having the opportunity to review first)? >> >> Sorry, absolutely not. I *really* want to review this in depth; if we >> make a mistake, it's going to hurt us significantly. > > Right but it's only a merge window - we can fix bugs and even disable > the new driver afterwards, can't we? Yes, but if we get something wrong we have to live with it. We made that mistake with virtio-pci the first time around... It isn't enough that the code 'works', it has to match the spec. And that requires careful thought and review. >> And until we have the qemu bits ready, it's really hard to tell if we've >> got this right. > > Sure, I meant if qemu bits are ready too, and if things work together. > It wouldn't do to merge a driver that isn't ready. > > >> So I'd rather delay and make sure we're solid. >> >> Thanks, >> Rusty. > > Something else we can do, is refactoring that splits driver > out to common and legacy bits, and changes APIs. > No? Yes, for sure. But there's no hurry to get those into the merge window. Cheers, Rusty. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Rusty away 18th September -- 11th October 2014-09-16 15:53 ` Rusty Russell @ 2014-09-16 16:20 ` Michael S. Tsirkin -1 siblings, 0 replies; 14+ messages in thread From: Michael S. Tsirkin @ 2014-09-16 16:20 UTC (permalink / raw) To: Rusty Russell; +Cc: Linus Torvalds, LKML, virtualization, netdev On Wed, Sep 17, 2014 at 01:23:46AM +0930, Rusty Russell wrote: > "Michael S. Tsirkin" <mst@redhat.com> writes: > > On Fri, Sep 12, 2014 at 10:58:03AM +0930, Rusty Russell wrote: > >> "Michael S. Tsirkin" <mst@redhat.com> writes: > >> > On Thu, Sep 11, 2014 at 10:26:52AM +0930, Rusty Russell wrote: > >> >> Hi all, > >> >> > >> >> Probably won't read mail. Linus, I'll have pull requests early > >> >> next week; if there's anything needed I'm sure Michael Tsirkin can > >> >> handle it. > >> > > >> > Sure. > >> > Rusty, there's a small chance virtio 1.0 bits will be ready in time. > >> > I started working on them based on your virtio-pci-new-layout branch. > >> > > >> > If ready before the merge window, are you ok with me merging this > >> > support (without you having the opportunity to review first)? > >> > >> Sorry, absolutely not. I *really* want to review this in depth; if we > >> make a mistake, it's going to hurt us significantly. > > > > Right but it's only a merge window - we can fix bugs and even disable > > the new driver afterwards, can't we? > > Yes, but if we get something wrong we have to live with it. We made > that mistake with virtio-pci the first time around... > > It isn't enough that the code 'works', it has to match the spec. And > that requires careful thought and review. > > >> And until we have the qemu bits ready, it's really hard to tell if we've > >> got this right. > > > > Sure, I meant if qemu bits are ready too, and if things work together. > > It wouldn't do to merge a driver that isn't ready. > > > > > >> So I'd rather delay and make sure we're solid. > >> > >> Thanks, > >> Rusty. > > > > Something else we can do, is refactoring that splits driver > > out to common and legacy bits, and changes APIs. > > No? > > Yes, for sure. But there's no hurry to get those into the merge window. > > Cheers, > Rusty. Well my point was if we do put them into the merge window, just adding a new driver will be easy and is often allowed pretty late in the cycle. -- MST ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Rusty away 18th September -- 11th October @ 2014-09-16 16:20 ` Michael S. Tsirkin 0 siblings, 0 replies; 14+ messages in thread From: Michael S. Tsirkin @ 2014-09-16 16:20 UTC (permalink / raw) To: Rusty Russell; +Cc: netdev, Linus Torvalds, LKML, virtualization On Wed, Sep 17, 2014 at 01:23:46AM +0930, Rusty Russell wrote: > "Michael S. Tsirkin" <mst@redhat.com> writes: > > On Fri, Sep 12, 2014 at 10:58:03AM +0930, Rusty Russell wrote: > >> "Michael S. Tsirkin" <mst@redhat.com> writes: > >> > On Thu, Sep 11, 2014 at 10:26:52AM +0930, Rusty Russell wrote: > >> >> Hi all, > >> >> > >> >> Probably won't read mail. Linus, I'll have pull requests early > >> >> next week; if there's anything needed I'm sure Michael Tsirkin can > >> >> handle it. > >> > > >> > Sure. > >> > Rusty, there's a small chance virtio 1.0 bits will be ready in time. > >> > I started working on them based on your virtio-pci-new-layout branch. > >> > > >> > If ready before the merge window, are you ok with me merging this > >> > support (without you having the opportunity to review first)? > >> > >> Sorry, absolutely not. I *really* want to review this in depth; if we > >> make a mistake, it's going to hurt us significantly. > > > > Right but it's only a merge window - we can fix bugs and even disable > > the new driver afterwards, can't we? > > Yes, but if we get something wrong we have to live with it. We made > that mistake with virtio-pci the first time around... > > It isn't enough that the code 'works', it has to match the spec. And > that requires careful thought and review. > > >> And until we have the qemu bits ready, it's really hard to tell if we've > >> got this right. > > > > Sure, I meant if qemu bits are ready too, and if things work together. > > It wouldn't do to merge a driver that isn't ready. > > > > > >> So I'd rather delay and make sure we're solid. > >> > >> Thanks, > >> Rusty. > > > > Something else we can do, is refactoring that splits driver > > out to common and legacy bits, and changes APIs. > > No? > > Yes, for sure. But there's no hurry to get those into the merge window. > > Cheers, > Rusty. Well my point was if we do put them into the merge window, just adding a new driver will be easy and is often allowed pretty late in the cycle. -- MST ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Rusty away 18th September -- 11th October 2014-09-11 0:56 ` Rusty Russell @ 2014-09-11 20:16 ` Linus Torvalds -1 siblings, 0 replies; 14+ messages in thread From: Linus Torvalds @ 2014-09-11 20:16 UTC (permalink / raw) To: Rusty Russell; +Cc: LKML, virtualization, netdev, Michael S. Tsirkin On Wed, Sep 10, 2014 at 5:56 PM, Rusty Russell <rusty@rustcorp.com.au> wrote: > > Probably won't read mail. Linus, I'll have pull requests early > next week; if there's anything needed I'm sure Michael Tsirkin can > handle it. So according to "normal timing", I would do the 3.17 release about three weeks from now, Oct 5th, and you would indeed be gone beginning of the next merge window. However, Oct 5th is also when I leave for LinuxCon EU, and while I am willing to sometimes do the second week of the merge window while traveling, doing the first week is just very impractical for me. That's when most of the big pull requests get merged, and when I want to do lots of allmodconfig builds etc, so doing it on the road is just not worth it. So right now my options are that (a) I can release 3.17 a week early (ie forego a rc7 entirely, and do the final 3.17 late September) and then just do the second week while traveling - something I've done many times or (b) just delay the merge window until after I come back (and whether that then delays 3.17 or not is a largely independent issue). 3.17 looks fine so far, and so maybe "skip rc7" is an option. It is the less likely one, I feel. I won't know until it happens, though. So having the pull request available early for next merge window is certainly much appreciated, but it may well be that you'll be back by the time I actually open it. I really have been cursed this year timing-wise wrt releases and travel. I haven't even traveled any more than previous years, but for some reason my travel dates have just been hitting the release dates constantly. > PS. England and Italy for a holiday; my daughter chose them (somehow I > forgot to inform her of the existence of Euro Disney...) Have fun. Linus ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Rusty away 18th September -- 11th October @ 2014-09-11 20:16 ` Linus Torvalds 0 siblings, 0 replies; 14+ messages in thread From: Linus Torvalds @ 2014-09-11 20:16 UTC (permalink / raw) To: Rusty Russell; +Cc: netdev, Michael S. Tsirkin, LKML, virtualization On Wed, Sep 10, 2014 at 5:56 PM, Rusty Russell <rusty@rustcorp.com.au> wrote: > > Probably won't read mail. Linus, I'll have pull requests early > next week; if there's anything needed I'm sure Michael Tsirkin can > handle it. So according to "normal timing", I would do the 3.17 release about three weeks from now, Oct 5th, and you would indeed be gone beginning of the next merge window. However, Oct 5th is also when I leave for LinuxCon EU, and while I am willing to sometimes do the second week of the merge window while traveling, doing the first week is just very impractical for me. That's when most of the big pull requests get merged, and when I want to do lots of allmodconfig builds etc, so doing it on the road is just not worth it. So right now my options are that (a) I can release 3.17 a week early (ie forego a rc7 entirely, and do the final 3.17 late September) and then just do the second week while traveling - something I've done many times or (b) just delay the merge window until after I come back (and whether that then delays 3.17 or not is a largely independent issue). 3.17 looks fine so far, and so maybe "skip rc7" is an option. It is the less likely one, I feel. I won't know until it happens, though. So having the pull request available early for next merge window is certainly much appreciated, but it may well be that you'll be back by the time I actually open it. I really have been cursed this year timing-wise wrt releases and travel. I haven't even traveled any more than previous years, but for some reason my travel dates have just been hitting the release dates constantly. > PS. England and Italy for a holiday; my daughter chose them (somehow I > forgot to inform her of the existence of Euro Disney...) Have fun. Linus ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2014-09-16 16:20 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-09-11 0:56 Rusty away 18th September -- 11th October Rusty Russell 2014-09-11 0:56 ` Rusty Russell 2014-09-11 11:43 ` Michael S. Tsirkin 2014-09-11 11:43 ` Michael S. Tsirkin 2014-09-12 1:28 ` Rusty Russell 2014-09-12 1:28 ` Rusty Russell 2014-09-14 6:21 ` Michael S. Tsirkin 2014-09-14 6:21 ` Michael S. Tsirkin 2014-09-16 15:53 ` Rusty Russell 2014-09-16 15:53 ` Rusty Russell 2014-09-16 16:20 ` Michael S. Tsirkin 2014-09-16 16:20 ` Michael S. Tsirkin 2014-09-11 20:16 ` Linus Torvalds 2014-09-11 20:16 ` Linus Torvalds
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.