Rusty away 18th September -- 11th October
Subsystems (3)
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...)
Michael S. Tsirkin
maintainerQuoted 5 lines · Rusty Russell
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)?
Signature · 1 line
MST
Quoted 7 lines · Michael S. Tsirkin
Quoted 5 lines · Rusty Russell
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.
Quoted 6 lines
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.
Michael S. Tsirkin
maintainerQuoted 12 lines · Rusty Russell
Quoted 11 lines · Michael S. Tsirkin
Quoted 5 lines · Rusty Russell
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.
Quoted 5 lines
Quoted 2 lines
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?
Quoted 2 lines
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.
Quoted 4 lines
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?
Signature · 1 line
MSt
Quoted 13 lines · Michael S. Tsirkin
Quoted 12 lines · Rusty Russell
Quoted 11 lines · Michael S. Tsirkin
Quoted 5 lines · Rusty Russell
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.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
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.
Quoted 7 lines
Quoted 2 lines
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.
Quoted 8 lines
Quoted 4 lines
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.
Michael S. Tsirkin
maintainerQuoted 41 lines · Rusty Russell
Quoted 13 lines · Michael S. Tsirkin
Quoted 12 lines · Rusty Russell
Quoted 11 lines · Michael S. Tsirkin
Quoted 5 lines · Rusty Russell
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.Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
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.
Quoted 12 lines
Quoted 2 lines
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.
Quoted 4 lines
So I'd rather delay and make sure we're solid.
Thanks,
Rusty.
Quoted 8 lines
Quoted 3 lines
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.
Signature · 1 line
MST
Quoted 4 lines · Rusty Russell
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.
Quoted 2 lines
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