[U-Boot] Custodian branch base commits

[Tom Rini]

On Tue, Oct 30, 2012 at 11:35:41AM -0600, Stephen Warren wrote:

> The instructions at:
> 
> http://www.denx.de/wiki/U-Boot/CustodianGitTrees
> 
> ... indicate that downstream branches should be rebased onto
> ${upstream}/master immediately prior to sending a pull request. I'm not
> sure this is correct any more, given that upstream master branches now
> pull in downstream branches via "git merge" rather than "git rebase".
> Should that page be changed?

Yes.

> The question then becomes: What commit should downstream branches use as
> their baseline. I assert that they should be free to choose any commit
> in their upstream master branch (or merge in any upstream commit), or
> any further upstream branch all the way up to u-boot/master.

I disagree.  It should be limited to your direct upstream only because..

> As background, I want to send a commit to the Tegra tree that enables
> use of CONFIG_CMD_FS_GENERIC, and additionally, re-write bootcmd in
> Tegra's default environment to use the new shell commands that config
> option enables.
> 
> However, the commits that implement CONFIG_CMD_FS_GENERIC are in
> u-boot/master but not yet in u-boot-arm/master. So, Tegra's master
> branch can't simply be based on current u-boot-arm/master, since if it
> was, applying my patch would break functionality until it was merged
> with u-boot/master and so picked up the actual implementation.

Yay for making use of new functionality, but..

> Hopefully, u-boot-arm/master will merge in (or get reset to)
> u-boot/master fairly shortly. However, should Tegra's repo have to wait
> for this?

Yes, tegra has to wait otherwise you've just forced u-boot-arm into a
re-sync with master and now u-boot-arm can't where problems came from,
be it your tree or master.  Patience is required, and I expect that
Albert will update to current master before starting his pull requests.
I also think it's fine to state that your pull request depends on $rev
being merged in prior to your pull.  But this is roughly how the kernel
trees work I believe.  You do a series of patches, state your
pre-request and deal with merging the changes up the different trees as
they are ready for it.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20121030/1fb7bfda/attachment.pgp>