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.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
