Hi Nicolas,
I noticed that a merge of Grant's ARM DT patches stack into linaro-stable is on the cards and this is good news.
I have a couple of questions on linaro-next though.
I think it is supposed to track mainline closely, and on this I'd ask your thoughts please since it does not seem to be so at present. It could be nice for us to have a development kernel to base our work against in order to get the latest mainline goodness (and to have a current base to test/develop patches coming from different git dev trees that are not in the mainline yet), but still trying to consolidate code for future linaro stable releases.
To sum it up, I am just asking you what are your plans for the linaro-next tree and the operating mode we should aim for.
Thank you very much indeed.
Cheers, Lorenzo
On Thu, 11 Nov 2010, Lorenzo Pieralisi wrote:
Hi Nicolas,
I noticed that a merge of Grant's ARM DT patches stack into linaro-stable is on the cards and this is good news.
Yes. Even if the DT patches are not yet guaranteed to go into mainline, I'm willing to merge them sooner in the hope of breaking the chicken and egg problem we're currently facing.
I have a couple of questions on linaro-next though.
I think it is supposed to track mainline closely, and on this I'd ask your thoughts please since it does not seem to be so at present.
Right, it is lagging behind at present.
It could be nice for us to have a development kernel to base our work against in order to get the latest mainline goodness (and to have a current base to test/develop patches coming from different git dev trees that are not in the mainline yet), but still trying to consolidate code for future linaro stable releases.
To that effect, I produced a new "stable" branch: linux-linaro-2.6.36. The core code is still 2.6.36 but most of the latest ARM specific bits and a few drivers to be found in 2.6.37-rc1 were merged into it.
To sum it up, I am just asking you what are your plans for the linaro-next tree and the operating mode we should aim for.
I'm still wondering about that myself at the moment. Obviously, the linaro-next is _not_ a good base for development. This is not a stable tree but rather a merge tree which is trashed and rebuilt from scratch every so often. It is therefore only useful for testing purposes. I'm therefore asking the question if it is actually useful, and if people did use it in the past. If not then I could probably spend my time on other tasks.
The alternative I'm contemplating, which came after the decision to merge DT patches in the Linaro "stable" tree, is to continue merging patches in that branch and not rebase it, for people to be able to use it as a base for their own development. The criteria for merging patches in this tree would be:
1) a patch to be merged is already in a later upstream tree, or
2) a proposed patch must have a high probability of being merged upstream in the future, and
3) only bugfixes would be merged once a new "stable" branch is available.
What do people think?
Nicolas
Hi Nicolas,
On Thu, 2010-11-11 at 17:38 +0000, Nicolas Pitre wrote:
On Thu, 11 Nov 2010, Lorenzo Pieralisi wrote:
To sum it up, I am just asking you what are your plans for the linaro-next tree and the operating mode we should aim for.
I'm still wondering about that myself at the moment. Obviously, the linaro-next is _not_ a good base for development. This is not a stable tree but rather a merge tree which is trashed and rebuilt from scratch every so often. It is therefore only useful for testing purposes. I'm therefore asking the question if it is actually useful, and if people did use it in the past. If not then I could probably spend my time on other tasks.
I haven't used it but I thought it's good for checking the integration of various trees which are not yet ready for the official -next tree (e.g. the FDT hasn't yet been endorsed by Russell, so not for mainline or -next at this point). It could be used for a bit more than just checking the merge conflicts. We could try compiling/running it and fixing bugs (which are then integrated in the original tree that caused them).
The alternative I'm contemplating, which came after the decision to merge DT patches in the Linaro "stable" tree, is to continue merging patches in that branch and not rebase it,
This may create additional work for people that use git rebase (or stgit etc.) in their workflow. Not really an issue if the lifetime of such tree is a mainline release cycle (i.e. you don't merge v2.6.37 into your 2.6.36 stable branch but create a new 2.6.37 branch). People could either freeze their stable tree to be merged into Linaro or use other methods of maintaining both a merge-friendly and a rebased branch with the same source ('stg publish' :)).
For example, our (Will's and mine) stable branch is no longer rebased once released but the next stable release wouldn't have a common history with the previous one. The development happens on the master branch (2.6.37-rc1 etc.)
for people to be able to use it as a base for their own development.
That's more of a 'political' issue IMHO and not related to the stable merging workflow (which looks fine to me).
My view (not necessarily ARM's, it's up to the advisory board to comment) is that we shouldn't encourage people to develop against the Linaro (stable) kernel but against mainline or some other upstream tree they depend on (e.g. Lorenzo developing against an FDT tree from Grant). I agree that in some situations it may be just easier to develop against the Linaro tree since people can avoid duplicating the integration effort that Linaro does.
So (again, IMHO) people that really need to develop against the Linaro kernel (maybe because they require features already integrated in the Linaro kernel) could rebase their work onto linaro-next. This way you prevent people from sending you pull requests for branches they maintain on top of the Linaro tree because of the merging conflicts in linaro-next. They would have to take the effort and base the tree against mainline or other dependent upstream before you can merge them.
The criteria for merging patches in this tree would be:
a patch to be merged is already in a later upstream tree, or
a proposed patch must have a high probability of being merged upstream in the future, and
only bugfixes would be merged once a new "stable" branch is available.
These look fine to me.
Thanks,
Catalin
On Fri, 12 Nov 2010, Catalin Marinas wrote:
Hi Nicolas,
On Thu, 2010-11-11 at 17:38 +0000, Nicolas Pitre wrote:
On Thu, 11 Nov 2010, Lorenzo Pieralisi wrote:
To sum it up, I am just asking you what are your plans for the linaro-next tree and the operating mode we should aim for.
I'm still wondering about that myself at the moment. Obviously, the linaro-next is _not_ a good base for development. This is not a stable tree but rather a merge tree which is trashed and rebuilt from scratch every so often. It is therefore only useful for testing purposes. I'm therefore asking the question if it is actually useful, and if people did use it in the past. If not then I could probably spend my time on other tasks.
I haven't used it but I thought it's good for checking the integration of various trees which are not yet ready for the official -next tree (e.g. the FDT hasn't yet been endorsed by Russell, so not for mainline or -next at this point).
It is endorsed by Linaro though, and I'm going to start merging the good pieces of DT into the stable Linaro kernels, per the discussion that happened at LDS.
It could be used for a bit more than just checking the merge conflicts. We could try compiling/running it and fixing bugs (which are then integrated in the original tree that caused them).
Obviously, and that was my rational for creating it in the first place. But after doing it for one cycle, I'm wondering if there are people to actually perform that testing.
The alternative I'm contemplating, which came after the decision to merge DT patches in the Linaro "stable" tree, is to continue merging patches in that branch and not rebase it,
This may create additional work for people that use git rebase (or stgit etc.) in their workflow. Not really an issue if the lifetime of such tree is a mainline release cycle (i.e. you don't merge v2.6.37 into your 2.6.36 stable branch but create a new 2.6.37 branch).
Absolutely! My intention is to move on to the next mainline release soon after it is released.
People could either freeze their stable tree to be merged into Linaro or use other methods of maintaining both a merge-friendly and a rebased branch with the same source ('stg publish' :)).
Sure, but I think that many Linaro members are not yet to that level of sophistication in their workflow. So instead of each member having to figure out a good base with the latest mainline stuff to port their patches to, I'm doing it centrally for everyone with an hybrid kernel (stable in the core code but up to date with the latest ARM bits). Basing their work on that tree should make development more "confortable" than chasing latest mainline, while making an eventual rebase for upstream submission easier.
My view (not necessarily ARM's, it's up to the advisory board to comment) is that we shouldn't encourage people to develop against the Linaro (stable) kernel but against mainline or some other upstream tree they depend on (e.g. Lorenzo developing against an FDT tree from Grant). I agree that in some situations it may be just easier to develop against the Linaro tree since people can avoid duplicating the integration effort that Linaro does.
Exactly my point.
So (again, IMHO) people that really need to develop against the Linaro kernel (maybe because they require features already integrated in the Linaro kernel) could rebase their work onto linaro-next. This way you prevent people from sending you pull requests for branches they maintain on top of the Linaro tree because of the merging conflicts in linaro-next. They would have to take the effort and base the tree against mainline or other dependent upstream before you can merge them.
... eventually. But some organizations aren't there yet. In the mean time I think that a smoother workflow transition can be accomplished with this branching of "stable" integration branches on top of each official mainline kernels. Rebasing from linux-linaro-2.6.36 to , say, mainline-2.6.37-rc5 for an upstream submission should then be fairly trivial.
Nicolas
-
Catalin Marinas -
Lorenzo Pieralisi -
Nicolas Pitre