On Thu, 2011-06-23 at 14:39 -0400, Nicolas Pitre wrote: > Half a year ago when I did ask for comments about the usefulness of the > linaro-next tree, I got almost no responses as I suspected, and I > therefore dropped that tree to concentrate my efforts on the Linaro > "stable" branches. If even the stable branch doesn't steer more > interest than it does now then this effort is just wasted. Either our > process is to blame, our priorities are wrong, or some efforts are > diverted where they shouldn't. > > One reason for the Linaro tree was to help LTs moving ahead rather than > sticking to ancient kernels. Now it seems that everyone wants to get > ahead of the actual latest release from kernel.org which is a radical > shift. Does this mean that vendors and co now are getting used to the > upstream pace and they're going to move to a rebasing workflow for real, > or they're just fooled by the marketing prospects of a meaningless major > kernel version bump? If the former that would be wonderful and maybe the > Linaro kernel outlived its usefulness. If the later... well... what can > I say here? > > In any case that doesn't make a strong case for the "Linaro" kernel. > We could as well just patch the latest Ubuntu kernel, the latest Android > kernel, or whatever existing distro or vendor kernel, in order to > showcase the Linaro initiated work and results. In practice that's what > I see people doing right now anyway. Pushing that work into mainline is > what matters the most in the end, and _that_ should always be Linaro's > top priority. > > I don't feel compelled to fight for the survival of the Linaro kernel > either if it is not widely used and significantly useful. I'm more > effective fighting with mainline kernel people: it is much more > interesting and useful with lasting results. > > Opinions anyone?
So first of all, Nico, you've been doing a great job maintaining the tree. Since the Linaro+Android tree is based on your tree, it doesn't take much work to maintain, but just the process of updating it and releasing it and keeping track of what changed takes time. You have this problem 100x fold tracking linus' tree and all the LT work, and have done a great job at it. You deserve a lot of credit for this, so I'm bummed to see your frustration here. The biggest concern for me is there being too many trees. Linaro has tons of git trees. Your tree, JohnR's tree, LT trees, etc (and this ignores the multiple android trees as well). I suspect this is why your linaro-next idea didn't get much response. While tracking mainline is great in my mind, it was one more tree to track, and was one more step removed from our release, and causes developer focus to be spread too thin. One issue I've had on the team is that when I want to test the Linaro nightly builds, I'm getting builds from JohnR's tree, which at times has been weeks behind the linaro tree. This puts the linaro tree in a ackward middle-ground, where its not mainline, but its also not tightly connected with the linaro builds, so it probably doesn't get the focus it should for both regular testing and the developed fixes. I did suggest earlier that we consider moving your tree to just be current with upstream Linaro ARM merge tree. The idea would be that LT developers would target Linus' HEAD, and we could then review and assist getting those patches queued into the linaro arm merge tree. This would help reduce the number of trees the SoC vendors have to interact with. Getting their patches into your tree would in effect be getting them upstream. Any stabilization effort on our part would be directly connected with the upstream stabilization. You'd have more time to focus on upstream and wouldn't have to keep track of what to back-port. Finally, our chorus of "upstream first" would be consistent with our releases. Now, there are some potential issues with this approach: 1) Cadence mis-match. We release monthly, Linus releases when its done. No clear way to align these other then potentially allowing for -rc2 based releases and the stability risks that might bring. 2) Puts possibly more work on us to really assist SoC developers in getting their patches merge-ready. Since they either get queued to go in or not, we couldn't be as laid back about stuff like the omap4 hdmi bits that got merged for release and dropped on rebase and merged for release and... etc. That said, this is a major part of our mission, so more focus here couldn't hurt, but it will take more hours of effort. 3) It doesn't do anything to address the issue you suggest that vendors might only working against 3.0 because 2.6.x sounds old. So when 3.1 or 3.2 shows up, if they are still focused on 3.0, we're in the same boat as before. I suspect it isn't just "3.0" mania, but instead a attempt to align to other releases (such as android picking 2.6.32, 2.6.35, 2.6.38 and now 3.0 for their big releases - much like how RH and SuSE do the same w/ enterprise releases on 2.6.32). Pushing for folks to work upstream always helps (since the next major FOO release is always around the corner), but I don't think we'll ever see this periodic focus go away. Anyway, I think we need to have a focus point. Your tree (along with all the hard work you put into it) is that focus point, so I think it would be terrible to throw it out. I just think aligning it with the upstream work you and Arnd and others are already doing would streamline and simplify things and hopefully further improve the focus on a single development tree. thanks -john _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
