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:
>
> 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.
These look fine to me.
Thanks,
Catalin
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
