Hi All, I am a freshman to linaro. I found people sent some patches to linaro-dev@lists.linaro.org. Here I have 2 questions: 1. Whether will linaro send those patches based on newest tree to Linus' mainline or not? Or developers need to send those patches to mainline by themselves? Is there any document to describe how linaro contribute patches to mainline? 2. If other SoC companies work based on linaro's linux-linaro-next.git, whether it will not need to work based on Linus' tree since linux-linaro-next.git will sync with mainline? Thanks Barry
Hi Barry,
I am a freshman to linaro. I found people sent some patches to linaro-dev@lists.linaro.org. Here I have 2 questions:
- Whether will linaro send those patches based on newest tree to
Linus' mainline or not? Or developers need to send those patches to mainline by themselves?
Authors need to post their own patches to the relevant mailing lists [1] for inclusion into the Mainline kernel.
Is there any document to describe how linaro contribute patches to
mainline?
As above.
- If other SoC companies work based on linaro's
linux-linaro-next.git, whether it will not need to work based on Linus' tree since linux-linaro-next.git will sync with mainline?
If your patches are going into Mainline, they will need to be built against the Mainline tree. If they are not going upstream, then the chances are they won't be accepted into the Linaro tree either.
[1] http://vger.kernel.org/vger-lists.html
Kind regards, Lee
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. 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? 2. will linaro accept patches from non-member companies and help to maintain, I mean a SoC company which doesn't join linaro?
Thanks Barry
2011/3/8 Lee Jones lee.jones@linaro.org:
Hi Barry,
I am a freshman to linaro. I found people sent some patches to linaro-dev@lists.linaro.org. Here I have 2 questions:
- Whether will linaro send those patches based on newest tree to
Linus' mainline or not? Or developers need to send those patches to mainline by themselves?
Authors need to post their own patches to the relevant mailing lists [1] for inclusion into the Mainline kernel.
Is there any document to describe how linaro contribute patches to
mainline?
As above.
- If other SoC companies work based on linaro's
linux-linaro-next.git, whether it will not need to work based on Linus' tree since linux-linaro-next.git will sync with mainline?
If your patches are going into Mainline, they will need to be built against the Mainline tree. If they are not going upstream, then the chances are they won't be accepted into the Linaro tree either.
[1] http://vger.kernel.org/vger-lists.html
Kind regards, Lee
On Tue, Mar 8, 2011 at 10:34 AM, Barry Song 21cnbao@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
- 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.
- 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.
/Amit
Thanks. Amit.
2011/3/8 Amit Kucheria amit.kucheria@linaro.org:
On Tue, Mar 8, 2011 at 10:34 AM, Barry Song 21cnbao@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
- 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.
- 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?
/Amit
On Wed, Mar 9, 2011 at 4:44 AM, Barry Song 21cnbao@gmail.com wrote:
Thanks. Amit.
2011/3/8 Amit Kucheria amit.kucheria@linaro.org:
<snip>
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?
It would depend on the patches, I guess. You can post them here to find out.
On 09/03/11 02:44, Barry Song wrote:
Thanks. Amit.
2011/3/8 Amit Kucheria amit.kucheria@linaro.org:
On Tue, Mar 8, 2011 at 10:34 AM, Barry Song 21cnbao@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
- 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.
- 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.
Thanks. Amit.
2011/3/9 Lee Jones lee.jones@linaro.org:
On 09/03/11 02:44, Barry Song wrote:
Thanks. Amit.
2011/3/8 Amit Kucheria amit.kucheria@linaro.org:
On Tue, Mar 8, 2011 at 10:34 AM, Barry Song 21cnbao@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
- 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.
- 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.
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?
On Fri, Mar 11, 2011 at 4:44 AM, Barry Song 21cnbao@gmail.com wrote:
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?
It would be more useful if you just posted the patches for review instead of waiting for confirmation from everyone involved. Code talks. :)
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.jones@linaro.org:
On 09/03/11 02:44, Barry Song wrote:
2011/3/8 Amit Kucheria amit.kucheria@linaro.org:
On Tue, Mar 8, 2011 at 10:34 AM, Barry Song 21cnbao@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
- 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
- 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
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@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.jones@linaro.org:
On 09/03/11 02:44, Barry Song wrote:
2011/3/8 Amit Kucheria amit.kucheria@linaro.org:
On Tue, Mar 8, 2011 at 10:34 AM, Barry Song 21cnbao@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
- 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
- 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
-
Amit Kucheria -
Barry Song -
Lee Jones -
Nicolas Pitre