[U-Boot] Pull request: u-boot-tegra/master

[Albert ARIBAUD <albert.u.boot@aribaud.net>]

Hi Stephen,

Le 08/12/2011 17:45, Stephen Warren a ?crit :
> On 12/08/2011 12:22 AM, Albert ARIBAUD wrote:
>> Hi Tom,
>>
>> Le 08/12/2011 00:35, Tom Warren a ?crit :
>>
>>> Albert,
>>>
>>> This is my first pull request for u-boot-tegra. Let me know if I?ve
>>> screwed it up in any way!
>>
>> Actually:
>>
>>> The following changes since commit 3865b6eba83707e1ad134bd42da426fd032948f5:
>>>
>>> MX35: flea3: changes due to hardware revision B (2011-12-05 18:31:20 +0100)
>>
>> ... This is not the current u-boot-arm/master branch tip, and rebasing
>> on it fails. Please rebase your master branch on top of
>> u-boot-arm/master ("davinci: Remove unwanted memsize.c from hawkboard's
>> nand spl build", commit id 15422043c4a213dc5d7d59a337be1ab34c9b2e7f)
>> then post a new pull request.
>
> Albert,
>
> Given that u-boot-arm/master is continually rebased, how would Tom avoid
> the following, which I think is what happened:
>
> 1) pull u-boot-arm/master
> 2) apply patches to it
> 3) test
> 4) send pull request
>
> ... while between (1) and (4), you've rebased u-boot-arm/master?
>
> I think in the Linux kernel world, this is avoided by having downstream
> branches based on stable branches in Linus' tree rather than directly
> on their upstream. This will still allow pull/merge to work fine, but
> means that there's never a time window that can invalidate the baseline
> the pull requests are based on.
>
> Would something like this work for U-Boot too?
>
> Or perhaps, u-boot-arm could publish a stable branch for downstream to
> base on, yet allow the rest of master to be rebased as needed?

Note: the rules I follow for pulling requests to u-boot-arm/master are 
actually those applying to u-boot/master, so I guess the issue you are 
raising with u-boot-arm could occur with u-boot/master as well -- it 
moves just like u-boot-arm does, after all.

That being said, I do not reject pull requests solely because they are 
not based on current u-boot-arm/master, precisely because I know it is a 
moving target at times. So if the request is not based on top of 
u-boot-arm/master, I try a rebase myself and if it succeeds trivially 
and I feel confident that there will be no interaction with the commits 
I've added in between, then I just accept the (now rebased) pull request 
-- this I have just done again a few days ago. If the pull request does 
not rebase trivially, then I ask the submitter to rebase because he's 
the best person to understand and solve the rebase conflict.

I believe this matches the intent of what you are proposing, but anyway, 
Wolfgang has the last word -- as usual. :)

Amicalement,
-- 
Albert.