[U-Boot] Custodian branch base commits

[Stephen Warren]

On 10/30/2012 03:19 PM, Tom Rini wrote:
> 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.

That is only true if the pull request sent to u-boot-arm from
u-boot-tegra is sent or processed before u-boot-arm pulls in the
u-boot commit that u-boot-tegra was based upon.

In other words, I don't think this issue requires that leaf repos be
based on a commit that's already in their immediate upstream repo, but
rather that leaf repos don't send a pull request to their upstream
repo until the leaf repo's baseline commit is included in their
upstream repo.

The difference here is that it would allow pipelining; leaf repos like
u-boot-tegra could grab the latest u-boot/master as a base, debug and
fix a bunch of bugs there, and be ready to send the pull request, all
in parallel with u-boot-arm actually pulling in u-boot/master.

Without this process, the Tegra maintainer has to synchronously wait
for the problematic commits to show up in u-boot-arm before he can
even apply fixes for them, even if the fixes are well known and fully
developed. Or, we try and apply patches to u-boot-tegra/master (based
only on u-boot-arm/master) that fix issues not yet in the branch, in a
way that when eventually merged into u-boot/master, the problems there
will be fixed. That's quite a lot harder in general!

> 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 that would imply that the git history in the pull request doesn't
actually build or run correctly on its own. The only way for it to
build or run correctly is for it to be actually based on the commit it
depends on. Simply stating patch dependencies works when sending
patches as a hint to say when to apply them, but as soon as something
is in git, it should work given the actual git history in that branch.

> 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.

For patches by email, yes.

For git merges/pulls, a variety of solutions exist:

* All the patches are applied to a single branch. This would require
the maintainer that would usually take a dependant patch to ack it so
that it can be taken through a different branch where the dependencies
are already present.

In this case, the change to use CONFIG_CMD_FS_GENERIC for Tegra could
be taken through u-boot/master rather than u-boot-tegra/master, with
the appropriate Ack from Tom Warren, since that's where the
implementation of CONFIG_CMD_FS_GENERIC was applied.

* The dependencies are placed into a topic branch, which itself is
based on an rc or release of the kernel, and this topic branch is
merged into all places that wish to apply patches that depend on the
topic branch. The topic branch gets pulled up into Linus' tree via
paths, which git handles just fine (at least for merges; duplicate
direct patch application would be more problematic and is generally
avoided).

* Or, development just gets synchronized every ~3 months via the
release process. However, that drastically slows the amount of forward
progress that can be made.