On 23 June 2011 11:39, Nicolas Pitre <nicolas.pi...@linaro.org> wrote: > On Thu, 23 Jun 2011, Andy Green wrote: > >> When linux-linaro-3.0 is coming in the next weeks, we will use that as a base >> instead as before. > > The base will be just as good as the contributions made by people to it. > And besides a few notable exceptions such as yours, I didn't get much > from people in terms of patches and/or pull requests. > > I'm seriously starting to question the usefulness of the "Linaro" kernel > tree in fact. For one year that I've been putting such a tree together, > the feedback and response have been less than overwhelming. The idea > was to _consolidate_ the work that the various groups within Linaro was > producing into a single and coherent whole without screwing up the other > groups' work, but so far this hasn't been a great success for various > reasons. > > > - Is solving the ARM fragmentation problem still a Linaro priority?
>From my POV, this is definitely a yes. > - Is the Linaro kernel effective for this? This I am not 100% sure about. I've seen quite a bit of activity on linux-arm-kernel after LDS with folks moving drivers out of arch/arm and I am beginning to see DT work being posted upstream. How much of that work is being send directly to you vs you having to stay on top of various changes in the community and pull those in proactively or as in the case of the ALSA issues, reactively? In other words, how much of your time is spent on keeping up with all the changes you need to pull into the Linaro kernel? This kernel is useful as place to test patches that are headed upstream in a single tree but unless all the LTs are using it as their base and are sending you patches on a regular basis, I do wonder if you're spending cycles on this tree that could be used on more core consolidation work. > 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? I don't know that we're hearing that all vendor trees want to be on the latest kernel. What I'm reading from Andy's perspective is that it is easier to just work directly against upstream changes that to try and figure out what all changes need to be picked into 2.6.39.. >From ST-E's landing team perspective, by the time they start on their work, it will be time for a 3.x tree. > 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. +1 I don't think it makes sense to have a Linaro-only tree for the sake of having a place to showcase Linaro's work. We don't want to be different from a kernel POV in my opinion. Our goal is to fix the kernel upstream, improve performance, consolidate architectures, help vendors cleanup their code. If we want to show case work, there are other ways to do it including just collating commit messages and providing high level summaries of work being done. > 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. My opinion is that if there are no patches coming in from within Linaro and all of the work you are doing is to simply integrate patches that are already upstream-bound, then we should just kill the Linaro tree and focus 100% on an upstream. Instead of having a "Linaro-branded" kernel, could we just have a branch in the arm-soc tree that is a consolidation branch and is widely used beyond just Linaro builds and that acts as a more public and upstream arm-next tree? ~Deepak _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
