[kvmarm] [GIT PULL v2] KVM/ARM Fixes for 3.9-rc1

[kvmarm] [GIT PULL v2] KVM/ARM Fixes for 3.9-rc1

[Christoffer Dall]

On Thu, Mar 7, 2013 at 11:09 AM, Marcelo Tosatti <mtosatti@redhat.com> wrote:
> On Thu, Mar 07, 2013 at 07:57:23AM +0100, Marc Zyngier wrote:
>> On Wed, 6 Mar 2013 20:40:00 -0800, Christoffer Dall
>> <cdall@cs.columbia.edu>
>> wrote:
>> > On Wed, Mar 6, 2013 at 7:54 PM, Marc Zyngier <marc.zyngier@arm.com>
>> wrote:
>> >> On Wed, 6 Mar 2013 16:31:48 -0800, Christoffer Dall
>> >> <cdall@cs.columbia.edu>
>> >> wrote:
>> >>
>> >> Hi Christoffer,
>> >>
>> >>>
>> >>> Please pull these KVM/ARM fixes mostly centered around preparation for
>> >>> Marc's ARMv8 KVM work.
>> >>
>> >> Can we please hold on that for a while? asm-offset.c is usually a
>> >> candidate for merge conflicts as people start pushing patches post
>> merge
>> >> window, and it would make sense to see what is happening in that space.
>> >>
>> > Sure, when would you see this happen exactly?
>>
>> Usually, by -rc5 we have a pretty good idea of what is going in. Also,
>> putting things into -next is a good way to detect potential problems.
>>
>> Oh, and keeping linux-arm-kernel into the loop. Most ARM developers don't
>> follow the KVM lists.
>>
>>         M.
>
> Mark, can you please be more verbose on the reason for this request?
>
> Christoffer, patches which are not causing merge conflicts can be
> integrated (note that the merge window exists so that development code
> can sit on a development branch and be tested before integration).
>
> After the merge window has closed, patches whose purpose is to stabilize
> the code base are supposed to be integrated, and development code queued
> for the next merge window.
>

Understood and agreed. Since the patches I sent a pull request for
fixes code (although not bugs) and are trivial and would not cause
breakage, I think they should be merged into kvm/master.  This is
anyhow going to be a judgement call in the future, and I can certainly
adjust my evaluations as we go along in the future, but I don't see
the harm in honoring this pull request.

-Christoffer

[kvmarm] [GIT PULL v2] KVM/ARM Fixes for 3.9-rc1

[Marc Zyngier]

On Thu, 7 Mar 2013 16:09:00 -0300, Marcelo Tosatti <mtosatti@redhat.com>
wrote:
> On Thu, Mar 07, 2013 at 07:57:23AM +0100, Marc Zyngier wrote:
>> On Wed, 6 Mar 2013 20:40:00 -0800, Christoffer Dall
>> <cdall@cs.columbia.edu>
>> wrote:
>> > On Wed, Mar 6, 2013 at 7:54 PM, Marc Zyngier <marc.zyngier@arm.com>
>> wrote:
>> >> On Wed, 6 Mar 2013 16:31:48 -0800, Christoffer Dall
>> >> <cdall@cs.columbia.edu>
>> >> wrote:
>> >>
>> >> Hi Christoffer,
>> >>
>> >>>
>> >>> Please pull these KVM/ARM fixes mostly centered around preparation
>> >>> for
>> >>> Marc's ARMv8 KVM work.
>> >>
>> >> Can we please hold on that for a while? asm-offset.c is usually a
>> >> candidate for merge conflicts as people start pushing patches post
>> merge
>> >> window, and it would make sense to see what is happening in that
>> >> space.
>> >>
>> > Sure, when would you see this happen exactly?
>> 
>> Usually, by -rc5 we have a pretty good idea of what is going in. Also,
>> putting things into -next is a good way to detect potential problems.
>> 
>> Oh, and keeping linux-arm-kernel into the loop. Most ARM developers
don't
>> follow the KVM lists.
>> 
>>         M.
> 
> Mark, can you please be more verbose on the reason for this request? 

arch/arm/kernel/asm-offset.c, being an ARM core file, is often the
location of merge conflicts. And because arch/arm sees a lot more churn
than any other architecture, we have the policy of dealing with conflicts
before they hit Linus.

We usually deal with that by providing stable branches that will contain
the "offending" patches, and on which others can base their developments.

This is why I suggested holding on this pull request until we got a better
view of what potential merge conflicts we get with this patches. This
shouldn't prevent the patches from entering -next though, as this would
help detecting the above conflicts.

Thanks,

        M.
-- 
Fast, cheap, reliable. Pick two.

[kvmarm] [GIT PULL v2] KVM/ARM Fixes for 3.9-rc1

[Gleb Natapov]

On Fri, Mar 08, 2013 at 04:12:41AM +0100, Marc Zyngier wrote:
> On Thu, 7 Mar 2013 16:09:00 -0300, Marcelo Tosatti <mtosatti@redhat.com>
> wrote:
> > On Thu, Mar 07, 2013 at 07:57:23AM +0100, Marc Zyngier wrote:
> >> On Wed, 6 Mar 2013 20:40:00 -0800, Christoffer Dall
> >> <cdall@cs.columbia.edu>
> >> wrote:
> >> > On Wed, Mar 6, 2013 at 7:54 PM, Marc Zyngier <marc.zyngier@arm.com>
> >> wrote:
> >> >> On Wed, 6 Mar 2013 16:31:48 -0800, Christoffer Dall
> >> >> <cdall@cs.columbia.edu>
> >> >> wrote:
> >> >>
> >> >> Hi Christoffer,
> >> >>
> >> >>>
> >> >>> Please pull these KVM/ARM fixes mostly centered around preparation
> >> >>> for
> >> >>> Marc's ARMv8 KVM work.
> >> >>
> >> >> Can we please hold on that for a while? asm-offset.c is usually a
> >> >> candidate for merge conflicts as people start pushing patches post
> >> merge
> >> >> window, and it would make sense to see what is happening in that
> >> >> space.
> >> >>
> >> > Sure, when would you see this happen exactly?
> >> 
> >> Usually, by -rc5 we have a pretty good idea of what is going in. Also,
> >> putting things into -next is a good way to detect potential problems.
> >> 
> >> Oh, and keeping linux-arm-kernel into the loop. Most ARM developers
> don't
> >> follow the KVM lists.
> >> 
> >>         M.
> > 
> > Mark, can you please be more verbose on the reason for this request? 
> 
> arch/arm/kernel/asm-offset.c, being an ARM core file, is often the
> location of merge conflicts. And because arch/arm sees a lot more churn
> than any other architecture, we have the policy of dealing with conflicts
> before they hit Linus.
> 
> We usually deal with that by providing stable branches that will contain
> the "offending" patches, and on which others can base their developments.
> 
Can you elaborate on that? If all changes to arch/arm/kernel/asm-offset.c not
go through the same tree how having many stable branches solve conflicts
issues?

> This is why I suggested holding on this pull request until we got a better
> view of what potential merge conflicts we get with this patches.
arch/arm/kernel/asm-offset.c in kvm.git:next will not change until 3.10-rc1
is released. What holding the pull request will give us?

>                                                                    This
> shouldn't prevent the patches from entering -next though, as this would
> help detecting the above conflicts.
> 
> Thanks,
> 
>         M.
> -- 
> Fast, cheap, reliable. Pick two.

--
			Gleb.

[kvmarm] [GIT PULL v2] KVM/ARM Fixes for 3.9-rc1

[Marc Zyngier]

On 08/03/13 11:31, Gleb Natapov wrote:
> On Fri, Mar 08, 2013 at 04:12:41AM +0100, Marc Zyngier wrote:
>> On Thu, 7 Mar 2013 16:09:00 -0300, Marcelo Tosatti <mtosatti@redhat.com>
>> wrote:
>>> On Thu, Mar 07, 2013 at 07:57:23AM +0100, Marc Zyngier wrote:
>>>> On Wed, 6 Mar 2013 20:40:00 -0800, Christoffer Dall
>>>> <cdall@cs.columbia.edu>
>>>> wrote:
>>>>> On Wed, Mar 6, 2013 at 7:54 PM, Marc Zyngier <marc.zyngier@arm.com>
>>>> wrote:
>>>>>> On Wed, 6 Mar 2013 16:31:48 -0800, Christoffer Dall
>>>>>> <cdall@cs.columbia.edu>
>>>>>> wrote:
>>>>>>
>>>>>> Hi Christoffer,
>>>>>>
>>>>>>>
>>>>>>> Please pull these KVM/ARM fixes mostly centered around preparation
>>>>>>> for
>>>>>>> Marc's ARMv8 KVM work.
>>>>>>
>>>>>> Can we please hold on that for a while? asm-offset.c is usually a
>>>>>> candidate for merge conflicts as people start pushing patches post
>>>> merge
>>>>>> window, and it would make sense to see what is happening in that
>>>>>> space.
>>>>>>
>>>>> Sure, when would you see this happen exactly?
>>>>
>>>> Usually, by -rc5 we have a pretty good idea of what is going in. Also,
>>>> putting things into -next is a good way to detect potential problems.
>>>>
>>>> Oh, and keeping linux-arm-kernel into the loop. Most ARM developers
>> don't
>>>> follow the KVM lists.
>>>>
>>>>         M.
>>>
>>> Mark, can you please be more verbose on the reason for this request? 
>>
>> arch/arm/kernel/asm-offset.c, being an ARM core file, is often the
>> location of merge conflicts. And because arch/arm sees a lot more churn
>> than any other architecture, we have the policy of dealing with conflicts
>> before they hit Linus.
>>
>> We usually deal with that by providing stable branches that will contain
>> the "offending" patches, and on which others can base their developments.
>>
> Can you elaborate on that? If all changes to arch/arm/kernel/asm-offset.c not
> go through the same tree how having many stable branches solve conflicts
> issues?

Patches for the conflicting file go to a stable branch (usually in RMK's
tree), and everyone else bases their own branch on the stable one.

	M.
-- 
Jazz is not dead. It just smells funny...

[kvmarm] [GIT PULL v2] KVM/ARM Fixes for 3.9-rc1

[Christoffer Dall]

On Thu, Mar 7, 2013 at 7:12 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> On Thu, 7 Mar 2013 16:09:00 -0300, Marcelo Tosatti <mtosatti@redhat.com>
> wrote:
>> On Thu, Mar 07, 2013 at 07:57:23AM +0100, Marc Zyngier wrote:
>>> On Wed, 6 Mar 2013 20:40:00 -0800, Christoffer Dall
>>> <cdall@cs.columbia.edu>
>>> wrote:
>>> > On Wed, Mar 6, 2013 at 7:54 PM, Marc Zyngier <marc.zyngier@arm.com>
>>> wrote:
>>> >> On Wed, 6 Mar 2013 16:31:48 -0800, Christoffer Dall
>>> >> <cdall@cs.columbia.edu>
>>> >> wrote:
>>> >>
>>> >> Hi Christoffer,
>>> >>
>>> >>>
>>> >>> Please pull these KVM/ARM fixes mostly centered around preparation
>>> >>> for
>>> >>> Marc's ARMv8 KVM work.
>>> >>
>>> >> Can we please hold on that for a while? asm-offset.c is usually a
>>> >> candidate for merge conflicts as people start pushing patches post
>>> merge
>>> >> window, and it would make sense to see what is happening in that
>>> >> space.
>>> >>
>>> > Sure, when would you see this happen exactly?
>>>
>>> Usually, by -rc5 we have a pretty good idea of what is going in. Also,
>>> putting things into -next is a good way to detect potential problems.
>>>
>>> Oh, and keeping linux-arm-kernel into the loop. Most ARM developers
> don't
>>> follow the KVM lists.
>>>
>>>         M.
>>
>> Mark, can you please be more verbose on the reason for this request?
>
> arch/arm/kernel/asm-offset.c, being an ARM core file, is often the
> location of merge conflicts. And because arch/arm sees a lot more churn
> than any other architecture, we have the policy of dealing with conflicts
> before they hit Linus.
>
> We usually deal with that by providing stable branches that will contain
> the "offending" patches, and on which others can base their developments.
>
> This is why I suggested holding on this pull request until we got a better
> view of what potential merge conflicts we get with this patches. This
> shouldn't prevent the patches from entering -next though, as this would
> help detecting the above conflicts.
>
So I think you need to explain me a little more carefully how the
'usually' applies in this case. This is just a pull request to the
kvm/master branch - it's not to Linus or ARM-specific. The only thing
is that we touch asm-offsets.c.

The only thing I can see that happens here is:
 - merge to kvm/master
 - kvm/master gets merged by Linus into -rcX (he fixes any merge
conflicts if present)
 - we, ARM, kvm, everyone, pull back from Linus

and that's it.

Perhaps it would be helpful if you can explain the situation we need
to avaoid and what exactly is the scenario when this breaks?

The merge conflicts in asm-offsets.c should be uber-trivial, so I'm
not sure what the big deal is.

-Christoffer

[kvmarm] [GIT PULL v2] KVM/ARM Fixes for 3.9-rc1

[Marc Zyngier]

On 08/03/13 19:26, Christoffer Dall wrote:
> On Thu, Mar 7, 2013 at 7:12 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
>> On Thu, 7 Mar 2013 16:09:00 -0300, Marcelo Tosatti <mtosatti@redhat.com>
>> wrote:
>>> On Thu, Mar 07, 2013 at 07:57:23AM +0100, Marc Zyngier wrote:
>>>> On Wed, 6 Mar 2013 20:40:00 -0800, Christoffer Dall
>>>> <cdall@cs.columbia.edu>
>>>> wrote:
>>>>> On Wed, Mar 6, 2013 at 7:54 PM, Marc Zyngier <marc.zyngier@arm.com>
>>>> wrote:
>>>>>> On Wed, 6 Mar 2013 16:31:48 -0800, Christoffer Dall
>>>>>> <cdall@cs.columbia.edu>
>>>>>> wrote:
>>>>>>
>>>>>> Hi Christoffer,
>>>>>>
>>>>>>>
>>>>>>> Please pull these KVM/ARM fixes mostly centered around preparation
>>>>>>> for
>>>>>>> Marc's ARMv8 KVM work.
>>>>>>
>>>>>> Can we please hold on that for a while? asm-offset.c is usually a
>>>>>> candidate for merge conflicts as people start pushing patches post
>>>> merge
>>>>>> window, and it would make sense to see what is happening in that
>>>>>> space.
>>>>>>
>>>>> Sure, when would you see this happen exactly?
>>>>
>>>> Usually, by -rc5 we have a pretty good idea of what is going in. Also,
>>>> putting things into -next is a good way to detect potential problems.
>>>>
>>>> Oh, and keeping linux-arm-kernel into the loop. Most ARM developers
>> don't
>>>> follow the KVM lists.
>>>>
>>>>         M.
>>>
>>> Mark, can you please be more verbose on the reason for this request?
>>
>> arch/arm/kernel/asm-offset.c, being an ARM core file, is often the
>> location of merge conflicts. And because arch/arm sees a lot more churn
>> than any other architecture, we have the policy of dealing with conflicts
>> before they hit Linus.
>>
>> We usually deal with that by providing stable branches that will contain
>> the "offending" patches, and on which others can base their developments.
>>
>> This is why I suggested holding on this pull request until we got a better
>> view of what potential merge conflicts we get with this patches. This
>> shouldn't prevent the patches from entering -next though, as this would
>> help detecting the above conflicts.
>>
> So I think you need to explain me a little more carefully how the
> 'usually' applies in this case. This is just a pull request to the
> kvm/master branch - it's not to Linus or ARM-specific. The only thing
> is that we touch asm-offsets.c.

Yes, and that's the issue. Core changes to the ARM code usually goes
through RMK in order to avoid conflicts. This is a long established
policy. It could be another tree (arm-soc, for example), but that's the
general idea.

At least getting an Ack from Russell so he knows about this patch seems
to be the minimum we could do.

> The only thing I can see that happens here is:
>  - merge to kvm/master
>  - kvm/master gets merged by Linus into -rcX (he fixes any merge
> conflicts if present)

And that's exactly what we've worked very hard to avoid. We don't let
conflicts go up to Linus.

>  - we, ARM, kvm, everyone, pull back from Linus
> 
> and that's it.
> 
> Perhaps it would be helpful if you can explain the situation we need
> to avaoid and what exactly is the scenario when this breaks?
> 
> The merge conflicts in asm-offsets.c should be uber-trivial, so I'm
> not sure what the big deal is.

Given that we don't know what is to be merged yet, your crystal ball is
as good as mine.

Anyway, I've said it. In the end, this is your decision as a maintainer.

	M.
-- 
Jazz is not dead. It just smells funny...

[kvmarm] [GIT PULL v2] KVM/ARM Fixes for 3.9-rc1

[Gleb Natapov]

On Mon, Mar 11, 2013 at 10:38:23AM +0000, Marc Zyngier wrote:
> On 08/03/13 19:26, Christoffer Dall wrote:
> > On Thu, Mar 7, 2013 at 7:12 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> >> On Thu, 7 Mar 2013 16:09:00 -0300, Marcelo Tosatti <mtosatti@redhat.com>
> >> wrote:
> >>> On Thu, Mar 07, 2013 at 07:57:23AM +0100, Marc Zyngier wrote:
> >>>> On Wed, 6 Mar 2013 20:40:00 -0800, Christoffer Dall
> >>>> <cdall@cs.columbia.edu>
> >>>> wrote:
> >>>>> On Wed, Mar 6, 2013 at 7:54 PM, Marc Zyngier <marc.zyngier@arm.com>
> >>>> wrote:
> >>>>>> On Wed, 6 Mar 2013 16:31:48 -0800, Christoffer Dall
> >>>>>> <cdall@cs.columbia.edu>
> >>>>>> wrote:
> >>>>>>
> >>>>>> Hi Christoffer,
> >>>>>>
> >>>>>>>
> >>>>>>> Please pull these KVM/ARM fixes mostly centered around preparation
> >>>>>>> for
> >>>>>>> Marc's ARMv8 KVM work.
> >>>>>>
> >>>>>> Can we please hold on that for a while? asm-offset.c is usually a
> >>>>>> candidate for merge conflicts as people start pushing patches post
> >>>> merge
> >>>>>> window, and it would make sense to see what is happening in that
> >>>>>> space.
> >>>>>>
> >>>>> Sure, when would you see this happen exactly?
> >>>>
> >>>> Usually, by -rc5 we have a pretty good idea of what is going in. Also,
> >>>> putting things into -next is a good way to detect potential problems.
> >>>>
> >>>> Oh, and keeping linux-arm-kernel into the loop. Most ARM developers
> >> don't
> >>>> follow the KVM lists.
> >>>>
> >>>>         M.
> >>>
> >>> Mark, can you please be more verbose on the reason for this request?
> >>
> >> arch/arm/kernel/asm-offset.c, being an ARM core file, is often the
> >> location of merge conflicts. And because arch/arm sees a lot more churn
> >> than any other architecture, we have the policy of dealing with conflicts
> >> before they hit Linus.
> >>
> >> We usually deal with that by providing stable branches that will contain
> >> the "offending" patches, and on which others can base their developments.
> >>
> >> This is why I suggested holding on this pull request until we got a better
> >> view of what potential merge conflicts we get with this patches. This
> >> shouldn't prevent the patches from entering -next though, as this would
> >> help detecting the above conflicts.
> >>
> > So I think you need to explain me a little more carefully how the
> > 'usually' applies in this case. This is just a pull request to the
> > kvm/master branch - it's not to Linus or ARM-specific. The only thing
> > is that we touch asm-offsets.c.
> 
> Yes, and that's the issue. Core changes to the ARM code usually goes
> through RMK in order to avoid conflicts. This is a long established
> policy. It could be another tree (arm-soc, for example), but that's the
> general idea.
> 
> At least getting an Ack from Russell so he knows about this patch seems
> to be the minimum we could do.
> 
Definitely.

Sometimes we have similar situation on x86 when some x86 KVM feature
requires non trivial change to core x86 code. We usually resolve it
in one of three ways. If KVM change is small and does not depend on
anything in kvm.git:next it can go through Ingo's tip tree along with
core change that it requires, or if core change is small it goes via KVM
tree with proper ACKs from x86 maintainers, or core changes go into Ingo's
non-rebase tree, the tree is merged into kvm.git:next and KVM changes are
applied on top. The disadvantage of the last approach is that we need to
wait before Linus pulls from Ingo before sending him KVM pull request,
but usually Ingo is the first to send pull requests anyway :) Of course
approach used is explicitly coordinated between KVM and x86 maintainers.

The point is that situation will not resolve itself by -rc5 magically,
so we need to solve it proactively. Can the patch series be separated
in such a way that changes to asm-offsets.c goes through rmk tree and
rest goes through kvm?

--
			Gleb.

[kvmarm] [GIT PULL v2] KVM/ARM Fixes for 3.9-rc1

[Christoffer Dall]

On Mon, Mar 11, 2013 at 3:38 AM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> On 08/03/13 19:26, Christoffer Dall wrote:
>> On Thu, Mar 7, 2013 at 7:12 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
>>> On Thu, 7 Mar 2013 16:09:00 -0300, Marcelo Tosatti <mtosatti@redhat.com>
>>> wrote:
>>>> On Thu, Mar 07, 2013 at 07:57:23AM +0100, Marc Zyngier wrote:
>>>>> On Wed, 6 Mar 2013 20:40:00 -0800, Christoffer Dall
>>>>> <cdall@cs.columbia.edu>
>>>>> wrote:
>>>>>> On Wed, Mar 6, 2013 at 7:54 PM, Marc Zyngier <marc.zyngier@arm.com>
>>>>> wrote:
>>>>>>> On Wed, 6 Mar 2013 16:31:48 -0800, Christoffer Dall
>>>>>>> <cdall@cs.columbia.edu>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Christoffer,
>>>>>>>
>>>>>>>>
>>>>>>>> Please pull these KVM/ARM fixes mostly centered around preparation
>>>>>>>> for
>>>>>>>> Marc's ARMv8 KVM work.
>>>>>>>
>>>>>>> Can we please hold on that for a while? asm-offset.c is usually a
>>>>>>> candidate for merge conflicts as people start pushing patches post
>>>>> merge
>>>>>>> window, and it would make sense to see what is happening in that
>>>>>>> space.
>>>>>>>
>>>>>> Sure, when would you see this happen exactly?
>>>>>
>>>>> Usually, by -rc5 we have a pretty good idea of what is going in. Also,
>>>>> putting things into -next is a good way to detect potential problems.
>>>>>
>>>>> Oh, and keeping linux-arm-kernel into the loop. Most ARM developers
>>> don't
>>>>> follow the KVM lists.
>>>>>
>>>>>         M.
>>>>
>>>> Mark, can you please be more verbose on the reason for this request?
>>>
>>> arch/arm/kernel/asm-offset.c, being an ARM core file, is often the
>>> location of merge conflicts. And because arch/arm sees a lot more churn
>>> than any other architecture, we have the policy of dealing with conflicts
>>> before they hit Linus.
>>>
>>> We usually deal with that by providing stable branches that will contain
>>> the "offending" patches, and on which others can base their developments.
>>>
>>> This is why I suggested holding on this pull request until we got a better
>>> view of what potential merge conflicts we get with this patches. This
>>> shouldn't prevent the patches from entering -next though, as this would
>>> help detecting the above conflicts.
>>>
>> So I think you need to explain me a little more carefully how the
>> 'usually' applies in this case. This is just a pull request to the
>> kvm/master branch - it's not to Linus or ARM-specific. The only thing
>> is that we touch asm-offsets.c.
>
> Yes, and that's the issue. Core changes to the ARM code usually goes
> through RMK in order to avoid conflicts. This is a long established
> policy. It could be another tree (arm-soc, for example), but that's the
> general idea.
>
> At least getting an Ack from Russell so he knows about this patch seems
> to be the minimum we could do.
>
>> The only thing I can see that happens here is:
>>  - merge to kvm/master
>>  - kvm/master gets merged by Linus into -rcX (he fixes any merge
>> conflicts if present)
>
> And that's exactly what we've worked very hard to avoid. We don't let
> conflicts go up to Linus.
>
>>  - we, ARM, kvm, everyone, pull back from Linus
>>
>> and that's it.
>>
>> Perhaps it would be helpful if you can explain the situation we need
>> to avaoid and what exactly is the scenario when this breaks?
>>
>> The merge conflicts in asm-offsets.c should be uber-trivial, so I'm
>> not sure what the big deal is.
>
> Given that we don't know what is to be merged yet, your crystal ball is
> as good as mine.
>
> Anyway, I've said it. In the end, this is your decision as a maintainer.
>
I certainly appreciate your input, and I definitely want to do this in
a way that makes the community happy, I'm just a bit confused about
exactly how the process should go, and I still don't quite see what
sending a pull request at -rc5 will give us. Maybe I'm being slow?

Otherwise, it sounds like I should simply send Russel a pull-request
for a specific branch made off one of his stable branches?

Is there an established branch to use or workflow (perhaps even
documented somewhere that I can look at), or do I have to send Russell
an e-mail requesting a stable branch and base my pull request off
there, or does something automagically happen at rc5?

-Christoffer