how to sync with mainline
21cnbao at gmail.com
Thu Mar 24 14:11:20 UTC 2011
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.pitre at 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
> On Fri, 11 Mar 2011, Barry Song wrote:
>> 2011/3/9 Lee Jones <lee.jones at linaro.org>:
>> > On 09/03/11 02:44, Barry Song wrote:
>> >> 2011/3/8 Amit Kucheria <amit.kucheria at linaro.org>:
>> >>> On Tue, Mar 8, 2011 at 10:34 AM, Barry Song <21cnbao at 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.
>> >>>> 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:
>> >>>> 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.
>> 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.
More information about the linaro-dev