Rusty away 18th September -- 11th October

Rusty away 18th September -- 11th October

[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.

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...)

Rusty away 18th September -- 11th October

[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.

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...)

Re: Rusty away 18th September -- 11th October

[Michael S. Tsirkin]

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

Re: Rusty away 18th September -- 11th October

[Michael S. Tsirkin]

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

Re: Rusty away 18th September -- 11th October

[Rusty Russell]

"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.

Re: Rusty away 18th September -- 11th October

[Rusty Russell]

"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.

Re: Rusty away 18th September -- 11th October

[Michael S. Tsirkin]

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

Re: Rusty away 18th September -- 11th October

[Michael S. Tsirkin]

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

Re: Rusty away 18th September -- 11th October

[Rusty Russell]

"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.

Re: Rusty away 18th September -- 11th October

[Rusty Russell]

"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.

Re: Rusty away 18th September -- 11th October

[Michael S. Tsirkin]

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

Re: Rusty away 18th September -- 11th October

[Michael S. Tsirkin]

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

Re: Rusty away 18th September -- 11th October

[Linus Torvalds]

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

Re: Rusty away 18th September -- 11th October

[Linus Torvalds]

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