The rebuilt branch is fine for me. My tree creation methodology is patterned after the Ubuntu kernel which means I rebase to new upstreams each release so I don't mind if my upstreams do as well.
John On Sun, Mar 27, 2011 at 10:06 PM, Nicolas Pitre <nicolas.pi...@linaro.org> wrote: > Hello everyone, > > As I've been working on the integration of the latest developments and > fixes from upstream into the linaro-2.6.38 kernel lately, it became > quickly evident that major merge conflicts were to be expected. The > problem stems from the fact that we opened the 2.6.38 branch early i.e. > around the 2.6.38-rc5 kernel. Many patches that were merged into the > Linaro kernel have been subsequently modified by their respective > maintainers until they were merged upstream, meaning that what we have > now in mainline is different from what the Linaro kernel tree has. This > creates several issues: > > - It is hard to verify that what is in the Linaro tree is actually the > latest and the best version of a patch. > > - Merging additional fixes from upstream often ends up in merge > conflicts requiring manual resolution, sometimes non-trivial ones, > which is in itself a bug hazard. > > - People wanting to contribute patches to the Linaro kernel potentially > have to create a different patch than what they would submit > upstream. > > Given those issues, I decided to rebuild the linaro-2.6.38 branch from > scratch to see where that would bring me. And as could be expected, the > result looks nicer and it is much easier to work with than the current > tree. For example, this allowed me to merge the latest OMAP support > from mainline as is, including the latest fixes, without any need for > backport work nor major conflict resolution. Another advantage is that > the commit SHA1 references are now identical in most cases to what can > be found into mainline. > > So... my question is: should we switch to this rebuilt tree or not? > There are drawbacks with such a move of course: > > - All the testing done so far would be void. This is however not as > bad as this may look as the rebuilt kernel contains fixes for existing > bugs in the current tree, and the rebuilt kernel is using patches > that have and still are being tested by a wider community. > > - I didn't forward port a couple series of patches that are available > in the current Linaro tree and not in mainline yet, including: > * DT support (Grant Likely) > * DVFS and PM for OMAP (Vishwanath Sripathy, Vishwanath BS) > * Some ux500 fixups (Linus Walleij) > * clock debug information (Yong Shen) > * Samsung CPUIDLE (Amit Kachhap) > So I would prefer if the people responsible for those patches did > resubmit their patches once they apply to the new tree (that should > be even easier now to apply patches that were meant for mainline). > > - The history of the rebuilt tree is obviously different from the > current tree's. This means special care when updating to the new > tree with Git. > > But overall I think there are more advantages than disadvantages for > such a move. What other people think? > > The current rebuilt tree can be seen at: > > http://git.linaro.org/gitweb?p=kernel/linux-linaro-2.6.38.git;a=shortlog;h=refs/heads/rebuilt > > or obtained from: > > git://git.linaro.org/kernel/linux-linaro-2.6.38.git (the "rebuilt" branch) > > > Nicolas > > _______________________________________________ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
