[U-Boot] How to manage RMOBILE patches?

[Tom Rini]

On 09/06/2012 12:28 PM, Albert ARIBAUD wrote:
> Hi Nobuhiro,
> 
> On Thu, 6 Sep 2012 08:20:59 +0900, Nobuhiro Iwamatsu
> <iwamatsu at nigauri.org> wrote:
> 
>> Hi, Tom.
>>
>> On Wed, Sep 5, 2012 at 11:17 PM, Tom Rini <trini at ti.com> wrote:
>>> On 09/05/2012 04:18 AM, Albert ARIBAUD wrote:
>>>> Hi Nobuhiro,
>>>>
>>>> On Wed, 5 Sep 2012 11:26:37 +0900, Nobuhiro Iwamatsu
>>>> <iwamatsu at nigauri.org> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> On Wed, Sep 5, 2012 at 2:36 AM, Tom Rini <trini at ti.com> wrote:
>>>>>> On Mon, Sep 03, 2012 at 09:15:56PM +0200, Wolfgang Denk wrote:
>>>>>>> Dear Nobuhiro Iwamatsu,
>>>>>>>
>>>>>>> In message
>>>>>>> <CABMQnVLBEEjcEtfTzdeThHfTLp=b24QSOgnFjbZr-8YWYTJUhg at mail.gmail.com>
>>>>>>> you wrote:
>>>>>>>>
>>>>>>>> I am working supporting  Renesas RMOBILE to U-Boot.
>>>>>>>> Renesas's RMOBILE SoC family contains an ARM Cortex-A9, and
>>>>>>>> this uses the same IP as SH.
>>>>>>>> (For example, timer, ether, serial, etc.)
>>>>>>>> I already sent to patches of rmobile, I got review from some
>>>>>>>> developers. And the patch is managed by the arm/rmobile branch
>>>>>>>> of u-boot-sh[0] which I have maintained, now.
>>>>>>>> Since I had you take the patch of rmobile into an ARM
>>>>>>>> repository, I consulted with Albert about the
>>>>>>>> future development approach.
>>>>>>>>
>>>>>>>> We thought two methods are considered.
>>>>>>>> One is Albert picks up a patch from ML to ARM repository,
>>>>>>>
>>>>>>> As this is ARM code, this appears the most natural approach to
>>>>>>> me
>>>>>>>
>>>>>>>> Another is whether to have pull from the repository by having a
>>>>>>>> repository for rmobile made.
>>>>>>>
>>>>>>> If this is an ARM SoC, then it should go through the ARM repo -
>>>>>>> even if we should later decide that there is so much traffic
>>>>>>> that a separate rmobile repo would be sustified, thi would
>>>>>>> still be a sub-repo, which Albert would pull from.
>>>>>>
>>>>>> Another option, which Mike is using for, iirc, sf and blackfin,
>>>>>> is just to add rmobile-master / rmobile-next as branches to the
>>>>>> u-boot-sh repository.
>>>>>
>>>>> Yes, this is one of easy way. But Albert won't  pull form
>>>>> u-boot-sh, if If my understanding is not wrong.
>>>>
>>>> This just means that they'll end up on u-boot/master from
>>>> u-boot.sh (and from there into u-boot-arm later on).
>>>
>>> To be clear, what I'm saying is just add a few more branches to
>>> u-boot-sh that Albert will pull (since they're ARM stuff).  Say
>>> u-boot-sh/rmobile/master and u-boot-sh/rmobile/next.  Then not get
>>> too hung up on which repository a merge message comes from. :)
>>>
>>
>> I was going to do by how to explain you.
>> However, I think that Albert mistook by my shortage of explanation.
>> Thank you for following up.
>>
>> Nobuhiro
> 
> I understand that some ARM patches would be stored in some branch
> (say rmobile/master) of the u-boot-sh repo and pull-requested to me
> from there.
> 
> What I still don't understand is *why* this should be done. Before they
> get on this branch, the patches would still have to go through the
> mailing list for review, just like the ARM patches that end up applied
> to u-boot-arm/master, except they'd have to do through an intermediate
> branch. If there are benefits in this, someone will have to lay them
> out for me, because right now I don't see them.

I think the answer is, given how you wish to work, there's not.  It's a
workflow problem only.  If it's no easier for you to get a pull request
from Nobuhiro once the patches have been reviewed than for you to pull
them out of patchwork once they have been reviewed, then since your
preference is for patchwork, via patchwork and into u-boot-arm is how
they'll work.

-- 
Tom