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.