Thank all of you very much. My all questions have got good answers. Comparing linaro kernel and mainline with same versions, there are a lot of backport, bug fixes and new feature commit logs in fact. Great!
2011/3/17 Nicolas Pitre <nicolas.pi...@linaro.org>: > > Sorry for not answering earlier. I was on vacation last week, and my > email backlog is incredibly large. I'm going through it with generous > usage of the delete key so it is possible that I might have missed > something. > > On Fri, 11 Mar 2011, Barry Song wrote: > >> 2011/3/9 Lee Jones <lee.jo...@linaro.org>: >> > On 09/03/11 02:44, Barry Song wrote: >> >> 2011/3/8 Amit Kucheria <amit.kuche...@linaro.org>: >> >>> On Tue, Mar 8, 2011 at 10:34 AM, Barry Song <21cn...@gmail.com> wrote: >> >>>> Hi Lee, >> >>>> Great! Thanks a lot. It looks like the communication between linaro >> >>>> and mainline is that linaro can backport some bug fixes and features >> >>>> from mainline to linaro tree. Linaro doesn't help to review patches >> >>>> and send to mainline. >> >>> We prefer to see it this way: >> >>> >> >>> Develop against mainline and get those features integrated there. Keep >> >>> linaro-dev in cc if these are features might be something Linaro would >> >>> care about. >> >>> >> >>> The Linaro kernel (maintained by Nicolas Pitre and packaged by John >> >>> Rigby) is a sort of technology demonstration to show what we achieve >> >>> every 6 months. Some patches in it are backports, others are features >> >>> that are still under review in mainline. But I doubt if Nicolas will >> >>> take un-reviewed code directly into his tree. > > Exact. > >> >>>> Then I have two more questions >> >>>> 1. is there a detailed list of backport and bug fix in linaro kernel >> >>>> tree since those are the difference between mainline and linaro tree? >> >>> 'git log' with the right incantations should be able to tell you that. >> >>> Look up Nicolas' email announcements for the high-level overview of >> >>> what he has integrated. > > The general policy for the Linaro kernel tree is described here: > > https://wiki.linaro.org/WorkingGroups/KernelConsolidation/KernelTree > >> >>>> 2. will linaro accept patches from non-member companies and help to >> >>>> maintain, I mean a SoC company which doesn't join linaro? >> >>> Linaro doesn't want to maintain dead code that isn't going upstream. >> >>> It won't even do it for member companies. At most it is the incubator >> >>> where the code lives and gets wider testing _while_ it is being >> >>> reworked for mainline. >> >> If patches are going mainline, but they are not from members TI, >> >> Freescale, ST-E etc, can they be merged into linaro kernel? >> > >> > I don't see any reason why not, but the overall decision will be made by >> > Nico. > > Yes they can, as long as there is some assurance that they are headed > for mainline as well. But the Linaro kernel won't help maintain > patches. Long term maintenance should be done in the upstream kernel. > >> That's important to market. In case customers of TI, Freescale, ST-E >> are also using SoC from non-member companies, since they are using >> linaro kernel and utilitis well on TI/Freescale/ST-E, >> they want to use the same linaro kernel on non-member chips, if linaro >> accepts and maintains non-member patches, then this tree can be useful >> and customers can use the only tree as their platform to support both >> member chips and non-member chips. > > Sure. > >> If so, maybe SoC companies don't need to join linaro, but they can get >> the benefit of linaro too. So what's the opinion of Nico? > > You should realize that for your patches to be merged into the Linaro > kernel, they must be in a similar state as if you were about to submit > them upstream. Therefore you must have made the effort of making your > code clean already. And once you're there, then you may just post them > for upstream inclusion as well -- that's always our ultimate goal. > > The advantage of having those patches also merged into the Linaro kernel > is all about early visibility and exposure. The latest developments > from upstream and the Linaro members are put together, in a kernel that > gets packaged and distributed along with user space components through > the Linaro infrastructure, to test and demonstrate the technology being > worked on without having to wait for the next upstream kernel release. > > Of course, if you are not a Linaro member, then you might have more > difficulties keeping up to date with the work being done in the various > groups as your platform won't be covered explicitly by those working > groups, and it won't be supported in the Linaro release. But your > patches would be accepted nevertheless, given that they also are on > their way to be merged upstream. > > I hope this helps. > > > Nicolas > _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
