Hi Oliver,
Answers in-line below.
On 8 Nov 2010, at 15:12, Oliver Grawert wrote:
hi,
at UDS we discussed the possibility of using linaro kernels for some of the ubuntu ARM flavours (currently for omap3 images but there might be more to come) where we seem to have duplicated efforts in kernel team and linaro ...
there were some open questions that require further discussion with a wider audience which i'd like to bring up in this mail:
- linaro kernels used in ubuntu ARM would need to move to the
supported package set (main) which makes them fall under all freeze restrictions the kernel team sets for ubuntu (only SRUs post kernel freeze, patches and changes all need to go through the ubuntu-kernel mailing list etc)
I think we can deal with the via the SRU process. We have already been using the SRU process this cycle for kernel changes so its a non-issue.
- configuration changes in the linaro kernels would have to happen to
match the ubuntu distro kernel configs in all places where they do not match yet (this also implies that ubuntu sauce needs to be added to the linaro kernels for making all distro features available)
I'm not sure Linaro want to carry the Ubuntu sauce and match configs. Linaro's continued effort to consolidate and stream-line kernels rather than expand options to cover all eventualities may conflict, this would need to be carefully investigated.
- someone has to commit to do security support for these kernels to
match the 18 months security support we provide for ubuntu images (can the ubuntu kernel team and the ubuntu security team commit to that ?)
This would be a problem for Linaro. Currently we have no support options that look like what you describe above. The only option at the moment would be for the Ubuntu Security Team to provide security support for the kernels once they come out of Linaro unless Linaro change their model.
if not all of the above bulletpoints (please shout if i missed any that are obvious) can be fulfulled we can not take linaro kernels for our images and another solution needs to be found.
I would love to see the sharing of kernels here. We need to come up with a good solution of which I don't have at the moment.
I've cc'd linaro-dev in to solicit more comments from the Linaro side.
ciao oli
Regards, Jamie.
hi, Am Montag, den 08.11.2010, 15:46 +0000 schrieb Jamie Bennett:
- linaro kernels used in ubuntu ARM would need to move to the
supported package set (main) which makes them fall under all freeze restrictions the kernel team sets for ubuntu (only SRUs post kernel freeze, patches and changes all need to go through the ubuntu-kernel mailing list etc)
I think we can deal with the via the SRU process. We have already been using the SRU process this cycle for kernel changes so its a non-issue.
well, the kernel freeze and SRU process would happen for you guys a lot earlier due to that, thats why i wanted to bring it up ...
- configuration changes in the linaro kernels would have to happen to
match the ubuntu distro kernel configs in all places where they do not match yet (this also implies that ubuntu sauce needs to be added to the linaro kernels for making all distro features available)
I'm not sure Linaro want to carry the Ubuntu sauce and match configs. Linaro's continued effort to consolidate and stream-line kernels rather than expand options to cover all eventualities may conflict, this would need to be carefully investigated.
one option i see is that we use the linaro branches as base and add all distro kernel specifics on top here, but thats something the kernel team has to agree to since they will have to be the ones doing that work (and i personally cant really judge how much work this is for them).
- someone has to commit to do security support for these kernels to
match the 18 months security support we provide for ubuntu images (can the ubuntu kernel team and the ubuntu security team commit to that ?)
This would be a problem for Linaro. Currently we have no support options that look like what you describe above. The only option at the moment would be for the Ubuntu Security Team to provide security support for the kernels once they come out of Linaro unless Linaro change their model.
right, i would like to hear something from the security team about this...
I would love to see the sharing of kernels here. We need to come up with a good solution of which I don't have at the moment.
I've cc'd linaro-dev in to solicit more comments from the Linaro side.
doing likewise with the ubuntu-kernel ML now, since i'm not sure they constantly read ubuntu-devel
ciao oli
Oliver,
On the subject of Ubuntu sauce and security patches, at each linaro kernel release I merge in the latest Ubuntu release so I believe the linaro packaged kernel has all these. My current plan is to continue doing to track the Ubuntu kernel as long as the Ubuntu kernel is supported.
On the configuration issue we have plans to reduce the enabled drivers in our kernel so we would probably need to build two versions of kernels that are consumed by both Linaro and Ubuntu.
On the SRU issue, I currently take everything that Nicolas has in his stable tree. We don't have a formal process for signing off patches on a mailing list. However, most patches in the stable tree are headed upstream and have been signed off on some other upstream list. There is a mismatch here between linaro (latest bleeding edge) and ubuntu (stable) requirements.
John
On Tue, Nov 9, 2010 at 7:22 AM, Oliver Grawert ogra@ubuntu.com wrote:
hi, Am Montag, den 08.11.2010, 15:46 +0000 schrieb Jamie Bennett:
- linaro kernels used in ubuntu ARM would need to move to the
supported package set (main) which makes them fall under all freeze restrictions the kernel team sets for ubuntu (only SRUs post kernel freeze, patches and changes all need to go through the ubuntu-kernel mailing list etc)
I think we can deal with the via the SRU process. We have already been using the SRU process this cycle for kernel changes so its a non-issue.
well, the kernel freeze and SRU process would happen for you guys a lot earlier due to that, thats why i wanted to bring it up ...
- configuration changes in the linaro kernels would have to happen to
match the ubuntu distro kernel configs in all places where they do not match yet (this also implies that ubuntu sauce needs to be added to the linaro kernels for making all distro features available)
I'm not sure Linaro want to carry the Ubuntu sauce and match configs. Linaro's continued effort to consolidate and stream-line kernels rather than expand options to cover all eventualities may conflict, this would need to be carefully investigated.
one option i see is that we use the linaro branches as base and add all distro kernel specifics on top here, but thats something the kernel team has to agree to since they will have to be the ones doing that work (and i personally cant really judge how much work this is for them).
- someone has to commit to do security support for these kernels to
match the 18 months security support we provide for ubuntu images (can the ubuntu kernel team and the ubuntu security team commit to that ?)
This would be a problem for Linaro. Currently we have no support options that look like what you describe above. The only option at the moment would be for the Ubuntu Security Team to provide security support for the kernels once they come out of Linaro unless Linaro change their model.
right, i would like to hear something from the security team about this...
I would love to see the sharing of kernels here. We need to come up with a good solution of which I don't have at the moment.
I've cc'd linaro-dev in to solicit more comments from the Linaro side.
doing likewise with the ubuntu-kernel ML now, since i'm not sure they constantly read ubuntu-devel
ciao oli
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On Tue, 9 Nov 2010, Oliver Grawert wrote:
hi, Am Montag, den 08.11.2010, 15:46 +0000 schrieb Jamie Bennett:
- linaro kernels used in ubuntu ARM would need to move to the
supported package set (main) which makes them fall under all freeze restrictions the kernel team sets for ubuntu (only SRUs post kernel freeze, patches and changes all need to go through the ubuntu-kernel mailing list etc)
I think we can deal with the via the SRU process. We have already been using the SRU process this cycle for kernel changes so its a non-issue.
well, the kernel freeze and SRU process would happen for you guys a lot earlier due to that, thats why i wanted to bring it up ...
While I see lots of goodness in trying to reduce this duplicated effort, I think there is still a slight disconnect between Linaro's and Ubuntu's goals for their respective kernels. While Ubuntu should focus on the greatest support to enhance the user experience, Linaro is there to promote support of the ARM architecture in general through consolidation towards the mainline kernel.
This means that, for example, that the Linaro kernel will not merge anything with no hope of ever being accepted upstream, including stuff like a single patch adding 45 thousand lines of code in one shot to support proprietary 3D graphics libraries. Now that we have a corporate backed entity to promote upstream contributions for the greater benefit of all members, we should not weaken this principle by carrying proprietary drivers with a dead future which would send a wrong signal.
However, the Ubuntu kernel has little choice but to merge those proprietary drivers as the unfortunate fact is that there is simply no alternative (yet) to produce a viable 3D user experience. And I'm afraid that this burden has to be carried on the Ubuntu side. Let's hope that the reduced engineering effort on the Ubuntu side due to the work now undertaken by the Linaro team will compensate for this continuing burden.
Linaro is also driving a work force which should serve the greater ARM Linux ecosystem, including Ubuntu on ARM of course, but other entities as well. Therefore the Linaro process cannot always be tied to the Ubuntu process. This means that Linaro may not always follow the exact same schedule as Ubuntu, and things like Ubuntu sauce patches and/or kernel configs might not make sense in all Linaro contexts.
one option i see is that we use the linaro branches as base and add all distro kernel specifics on top here, but thats something the kernel team has to agree to since they will have to be the ones doing that work (and i personally cant really judge how much work this is for them).
I'm afraid this might have to be the case. However, Git is pretty powerful and effective to carry such a task. Of course, for anything that should move towards mainline, it is best if Linaro carries such patches directly instead of Ubuntu.
Nicolas
On Tue, Nov 9, 2010 at 6:58 PM, Nicolas Pitre nicolas.pitre@linaro.org wrote:
On Tue, 9 Nov 2010, Oliver Grawert wrote:
hi, Am Montag, den 08.11.2010, 15:46 +0000 schrieb Jamie Bennett:
- linaro kernels used in ubuntu ARM would need to move to the
supported package set (main) which makes them fall under all freeze restrictions the kernel team sets for ubuntu (only SRUs post kernel freeze, patches and changes all need to go through the ubuntu-kernel mailing list etc)
I think we can deal with the via the SRU process. We have already been using the SRU process this cycle for kernel changes so its a non-issue.
well, the kernel freeze and SRU process would happen for you guys a lot earlier due to that, thats why i wanted to bring it up ...
While I see lots of goodness in trying to reduce this duplicated effort, I think there is still a slight disconnect between Linaro's and Ubuntu's goals for their respective kernels. While Ubuntu should focus on the greatest support to enhance the user experience, Linaro is there to promote support of the ARM architecture in general through consolidation towards the mainline kernel.
This means that, for example, that the Linaro kernel will not merge anything with no hope of ever being accepted upstream, including stuff like a single patch adding 45 thousand lines of code in one shot to support proprietary 3D graphics libraries. Now that we have a corporate backed entity to promote upstream contributions for the greater benefit of all members, we should not weaken this principle by carrying proprietary drivers with a dead future which would send a wrong signal.
However, the Ubuntu kernel has little choice but to merge those proprietary drivers as the unfortunate fact is that there is simply no alternative (yet) to produce a viable 3D user experience. And I'm afraid that this burden has to be carried on the Ubuntu side. Let's hope that the reduced engineering effort on the Ubuntu side due to the work now undertaken by the Linaro team will compensate for this continuing burden.
That's understandable. Now the question is why John is maintaining and packaging a tree that also incorporate the Ubuntu sauce on it?
Linaro is also driving a work force which should serve the greater ARM Linux ecosystem, including Ubuntu on ARM of course, but other entities as well. Therefore the Linaro process cannot always be tied to the Ubuntu process. This means that Linaro may not always follow the exact same schedule as Ubuntu, and things like Ubuntu sauce patches and/or kernel configs might not make sense in all Linaro contexts.
I also agree on this one. I believe that now that Linaro is getting more popular and used by other entities, makes no much sense in maintaining something that will be used by Ubuntu. Only a reference and maintained tree would probably be enough in case distros want to incorporate it.
one option i see is that we use the linaro branches as base and add all distro kernel specifics on top here, but thats something the kernel team has to agree to since they will have to be the ones doing that work (and i personally cant really judge how much work this is for them).
I'm afraid this might have to be the case. However, Git is pretty powerful and effective to carry such a task.
This will probably be the case. At least it's the one that makes more sense in the Linaro's perspective.
Now the question is, are we sure that this will actually reduce the workflow for the Ubuntu kernel team? I know in case of Omap 3 it was one additional flavor, but was somehow OK because it follows upstream and they are already used with it. Having the Linaro tree as reference instead of upstream will probably produce a better ARM kernel, but it seems that it'll give more work to the kernel team, instead of making things easier.
On Thu, 11 Nov 2010, Ricardo Salveti wrote:
On Tue, Nov 9, 2010 at 6:58 PM, Nicolas Pitre nicolas.pitre@linaro.org wrote:
On Tue, 9 Nov 2010, Oliver Grawert wrote:
hi, Am Montag, den 08.11.2010, 15:46 +0000 schrieb Jamie Bennett:
- linaro kernels used in ubuntu ARM would need to move to the
supported package set (main) which makes them fall under all freeze restrictions the kernel team sets for ubuntu (only SRUs post kernel freeze, patches and changes all need to go through the ubuntu-kernel mailing list etc)
I think we can deal with the via the SRU process. We have already been using the SRU process this cycle for kernel changes so its a non-issue.
well, the kernel freeze and SRU process would happen for you guys a lot earlier due to that, thats why i wanted to bring it up ...
While I see lots of goodness in trying to reduce this duplicated effort, I think there is still a slight disconnect between Linaro's and Ubuntu's goals for their respective kernels. While Ubuntu should focus on the greatest support to enhance the user experience, Linaro is there to promote support of the ARM architecture in general through consolidation towards the mainline kernel.
This means that, for example, that the Linaro kernel will not merge anything with no hope of ever being accepted upstream, including stuff like a single patch adding 45 thousand lines of code in one shot to support proprietary 3D graphics libraries. Now that we have a corporate backed entity to promote upstream contributions for the greater benefit of all members, we should not weaken this principle by carrying proprietary drivers with a dead future which would send a wrong signal.
However, the Ubuntu kernel has little choice but to merge those proprietary drivers as the unfortunate fact is that there is simply no alternative (yet) to produce a viable 3D user experience. And I'm afraid that this burden has to be carried on the Ubuntu side. Let's hope that the reduced engineering effort on the Ubuntu side due to the work now undertaken by the Linaro team will compensate for this continuing burden.
That's understandable. Now the question is why John is maintaining and packaging a tree that also incorporate the Ubuntu sauce on it?
I think that the main reason is that this was much easier to have a packaged initial release by simply piggybacking on the existing Ubuntu infrastructure. But John's tree and mine are still separate.
one option i see is that we use the linaro branches as base and add all distro kernel specifics on top here, but thats something the kernel team has to agree to since they will have to be the ones doing that work (and i personally cant really judge how much work this is for them).
I'm afraid this might have to be the case. However, Git is pretty powerful and effective to carry such a task.
This will probably be the case. At least it's the one that makes more sense in the Linaro's perspective.
Now the question is, are we sure that this will actually reduce the workflow for the Ubuntu kernel team? I know in case of Omap 3 it was one additional flavor, but was somehow OK because it follows upstream and they are already used with it. Having the Linaro tree as reference instead of upstream will probably produce a better ARM kernel, but it seems that it'll give more work to the kernel team, instead of making things easier.
What extra work do you see? Maybe we could discuss it?
Nicolas
On Thu, Nov 11, 2010 at 4:02 PM, Nicolas Pitre nicolas.pitre@canonical.com wrote:
On Tue, 9 Nov 2010, Oliver Grawert wrote:
On Thu, 11 Nov 2010, Ricardo Salveti wrote:
That's understandable. Now the question is why John is maintaining and packaging a tree that also incorporate the Ubuntu sauce on it?
I think that the main reason is that this was much easier to have a packaged initial release by simply piggybacking on the existing Ubuntu infrastructure. But John's tree and mine are still separate.
Ok, so there's nothing that guarantees that John will continue using the same Ubuntu infrastructure and sauce in the future.
one option i see is that we use the linaro branches as base and add all distro kernel specifics on top here, but thats something the kernel team has to agree to since they will have to be the ones doing that work (and i personally cant really judge how much work this is for them).
I'm afraid this might have to be the case. However, Git is pretty powerful and effective to carry such a task.
This will probably be the case. At least it's the one that makes more sense in the Linaro's perspective.
Now the question is, are we sure that this will actually reduce the workflow for the Ubuntu kernel team? I know in case of Omap 3 it was one additional flavor, but was somehow OK because it follows upstream and they are already used with it. Having the Linaro tree as reference instead of upstream will probably produce a better ARM kernel, but it seems that it'll give more work to the kernel team, instead of making things easier.
What extra work do you see? Maybe we could discuss it?
Probably the work needed to track and merge another tree into the ARM related ones. Currently they just need to worry about the upstream tree, and to carry the Ubuntu sauce on it. Having and additional kernel tree to track and merge will give some more work than they had for Maverick, because they will have more patches to review and to maintain, in case of conflicts and etc.
I know this all makes sense, and it's good for the quality of both ubuntu and linaro's kernel, but it gives the impression that they will end up dealing with more work than they had for Maverick.
Folks, I think this thread is circling a bit back to itself, perhaps summarizing where we stand and what problems we're trying to solve would help?
* Linaro integrates its kernel tree into Ubuntu for two reasons: - because Linaro uses Ubuntu as a base to build its own derived images (out of Ubuntu) - because Linaro wants its kernel shipped/available in distributions such as Ubuntu/MeeGo/whatever for mutual benefit of the distro and of Linaro. For instance, Ubuntu users could install this kernel instead of the official Ubuntu one, or Ubuntu could build images from this kernel (as proposed in the original email).
* there are currently the following *three* trees for the Ubuntu Linaro kernel packages to happen (for maverick): - git://git.linaro.org/kernel/linux-linaro-2.6.35.git -- upstreamish tree maintained by Nicolas, based on upstream git tree with patches relevant to Linaro merged in; the Linaro Kernel - git://git.linaro.org/ubuntu/linux-linaro.git -- Ubuntu-ish tree for the linux-linaro source package in Ubuntu or in Linaro PPAs maintained by jcrigby, based on the Linaro Kernel tree with packaging and the Ubuntu stuff ("Sauce") merged in - git://kernel.ubuntu.com/ubuntu/ubuntu-maverick.git linaro branch -- pretty much the same as jcrigby's tree maintained by the Ubuntu kernel team; it's mostly a copy of jcrigby's tree when it gets uploaded to Ubuntu, unless the Ubuntu kernel team has to do any minor adjustments/fixups before upload; it exists only because jcrigby can't upload and because /ubuntu is restricted to the official Ubuntu Kernel Team
So what problems / questions are we trying to solve? * security support: Linaro isn't in the business of long-term security support of its trees, however I understand that it wouldn't be a big problem to simply add the *Ubuntu* linux-linaro package and the kernel.ubuntu.com git tree to the list of packages/trees which get security updates from the Ubuntu Security Team, especially if the Ubuntu ARM Team moves to this package/tree as their base for some images * for Linaro, the Ubuntu Sauce stuff doesn't add any much value and is a distraction (causes more merge efforts, might cause extra bugs etc.)
Is this a fair summary? Did I miss anything?
I am not sure I understand the point of contention with the Ubuntu Sauce stuff; is it causing problems to Linaro right now? Linaro GCC is released in source form and then integrated in the Ubuntu gcc-4.x packages which have tons of patches added on top; this is not ideal for Linaro Toolchain WG, but it's part of the process to check whether bugs do apply to the pristine Linaro source, just like you need to test a pristine upstream GCC or Linux when reporting bugs upstream.
There are definitely things we could do to improve the Ubuntu Sauce: * split this stuff more; e.g.: - packaging goes in one tree (I think this is already split out?) - patches which come from upstream or were acked upstream go into another tree - patches which are Ubuntu specific such as AUFS go into one or multiple separate trees * we could review the current sauce stuff and only merge in features which are really needed for Linaro images and Ubuntu ARM images; aufs doesn't seem to be needed anymore for instance? Maybe this makes things more complex for little gain though * we could stop merging patches from upstream from Ubuntu, and have them flow in via Linaro instead; again, maybe this makes things more complex for little gain
My opinion is that the current approach is okay modulo two things: - we should drop one of the two packaging trees; the linaro / jcrigby versus kernel.ubuntu.com split is useless - we could provide pristine kernel builds, built from the Linaro Kernel directly and without any Ubuntu Sauce . in fact these exist already, they just aren't tested and they use a random config: http://hudson.dooz.org/ . if we want Linaro Kernel .debs instead of standalone zImage/uImage, we could do something like https://wiki.ubuntu.com/Kernel/MainlineBuilds
Proposed plan: * Oliver/Ricardo to confirm with Ubuntu Security Team whether it's ok to base Ubuntu ARM images on linux-linaro tree as constructed currently * John to request upload permissions for linux-linaro only and to request commit rights to ubuntu/ubuntu-$release.git for the linaro branch only * if someone cares about limiting the Ubuntu Sauce which goes into the linux-linaro Ubuntu package which goes into Linaro images, then that someone ought to start discussion on splitting and limiting the Sauce which goes into the linaro branch with the Ubuntu Kernel Team; I don't think this fundamentally holds up anything though * if someone cares about providing better vanilla Linaro Kernel builds, e.g. .debs, then that someone ought to start some spec on providing + testing these builds -- I'm happy to help here :-)
Cheers,
On Mon, Nov 15, 2010 at 4:28 AM, Loïc Minier loic.minier@ubuntu.com wrote:
Folks, I think this thread is circling a bit back to itself, perhaps summarizing where we stand and what problems we're trying to solve would help?
* Linaro integrates its kernel tree into Ubuntu for two reasons: - because Linaro uses Ubuntu as a base to build its own derived images (out of Ubuntu) - because Linaro wants its kernel shipped/available in distributions such as Ubuntu/MeeGo/whatever for mutual benefit of the distro and of Linaro. For instance, Ubuntu users could install this kernel instead of the official Ubuntu one, or Ubuntu could build images from this kernel (as proposed in the original email).
* there are currently the following *three* trees for the Ubuntu Linaro kernel packages to happen (for maverick): - git://git.linaro.org/kernel/linux-linaro-2.6.35.git -- upstreamish tree maintained by Nicolas, based on upstream git tree with patches relevant to Linaro merged in; the Linaro Kernel - git://git.linaro.org/ubuntu/linux-linaro.git -- Ubuntu-ish tree for the linux-linaro source package in Ubuntu or in Linaro PPAs maintained by jcrigby, based on the Linaro Kernel tree with packaging and the Ubuntu stuff ("Sauce") merged in - git://kernel.ubuntu.com/ubuntu/ubuntu-maverick.git linaro branch -- pretty much the same as jcrigby's tree maintained by the Ubuntu kernel team; it's mostly a copy of jcrigby's tree when it gets uploaded to Ubuntu, unless the Ubuntu kernel team has to do any minor adjustments/fixups before upload; it exists only because jcrigby can't upload and because /ubuntu is restricted to the official Ubuntu Kernel Team
So what problems / questions are we trying to solve? * security support: Linaro isn't in the business of long-term security support of its trees, however I understand that it wouldn't be a big problem to simply add the *Ubuntu* linux-linaro package and the kernel.ubuntu.com git tree to the list of packages/trees which get security updates from the Ubuntu Security Team, especially if the Ubuntu ARM Team moves to this package/tree as their base for some images * for Linaro, the Ubuntu Sauce stuff doesn't add any much value and is a distraction (causes more merge efforts, might cause extra bugs etc.)
Is this a fair summary? Did I miss anything?
I am not sure I understand the point of contention with the Ubuntu Sauce stuff; is it causing problems to Linaro right now? Linaro GCC is released in source form and then integrated in the Ubuntu gcc-4.x packages which have tons of patches added on top; this is not ideal for Linaro Toolchain WG, but it's part of the process to check whether bugs do apply to the pristine Linaro source, just like you need to test a pristine upstream GCC or Linux when reporting bugs upstream.
There are definitely things we could do to improve the Ubuntu Sauce: * split this stuff more; e.g.: - packaging goes in one tree (I think this is already split out?) - patches which come from upstream or were acked upstream go into another tree - patches which are Ubuntu specific such as AUFS go into one or multiple separate trees * we could review the current sauce stuff and only merge in features which are really needed for Linaro images and Ubuntu ARM images; aufs doesn't seem to be needed anymore for instance? Maybe this makes things more complex for little gain though * we could stop merging patches from upstream from Ubuntu, and have them flow in via Linaro instead; again, maybe this makes things more complex for little gain
My opinion is that the current approach is okay modulo two things: - we should drop one of the two packaging trees; the linaro / jcrigby versus kernel.ubuntu.com split is useless - we could provide pristine kernel builds, built from the Linaro Kernel directly and without any Ubuntu Sauce . in fact these exist already, they just aren't tested and they use a random config: http://hudson.dooz.org/ . if we want Linaro Kernel .debs instead of standalone zImage/uImage, we could do something like https://wiki.ubuntu.com/Kernel/MainlineBuilds
Proposed plan: * Oliver/Ricardo to confirm with Ubuntu Security Team whether it's ok to base Ubuntu ARM images on linux-linaro tree as constructed currently
I can't speak for the Ubuntu ARM folks but I believe their main concern was if I stopped including Ubuntu Sauce.
* John to request upload permissions for linux-linaro only and to request commit rights to ubuntu/ubuntu-$release.git for the linaro branch only
The plan proposed at UDS was for Steve Langasek to take over the roll of linux-linaro upload sponsor. He would replace Tim G in this role. Perhaps we could try this for one cycle then consider the idea of me uploading after that.
* if someone cares about limiting the Ubuntu Sauce which goes into the linux-linaro Ubuntu package which goes into Linaro images, then that someone ought to start discussion on splitting and limiting the Sauce which goes into the linaro branch with the Ubuntu Kernel Team; I don't think this fundamentally holds up anything though
The easiest way to include Ubuntu Sauce is to include all of it. It rarely causes merge conflicts and I can't think of an instance where it has caused breakage for linux-linaro so I suggest we just keep including it all. To include a subset would require someone to decide what subset and that would be extra work.
* if someone cares about providing better vanilla Linaro Kernel builds, e.g. .debs, then that someone ought to start some spec on providing + testing these builds -- I'm happy to help here :-)
Cheers,
Loïc Minier
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Good discussion. Stupid question - what is the Ubuntu sauce? I'll ask the kernel dudes in their meeting in two minutes...
Dave
On 15 Nov 2010, at 15:53, John Rigby wrote:
On Mon, Nov 15, 2010 at 4:28 AM, Loïc Minier loic.minier@ubuntu.com wrote:
Folks, I think this thread is circling a bit back to itself, perhaps summarizing where we stand and what problems we're trying to solve would help?
- Linaro integrates its kernel tree into Ubuntu for two reasons:
- because Linaro uses Ubuntu as a base to build its own derived images (out of Ubuntu)
- because Linaro wants its kernel shipped/available in distributions such as Ubuntu/MeeGo/whatever for mutual benefit of the distro and of Linaro. For instance, Ubuntu users could install this kernel instead of the official Ubuntu one, or Ubuntu could build images from this kernel (as proposed in the original email).
- there are currently the following *three* trees for the Ubuntu Linaro
kernel packages to happen (for maverick):
- git://git.linaro.org/kernel/linux-linaro-2.6.35.git -- upstreamish tree maintained by Nicolas, based on upstream git tree with patches relevant to Linaro merged in; the Linaro Kernel
- git://git.linaro.org/ubuntu/linux-linaro.git -- Ubuntu-ish tree for the linux-linaro source package in Ubuntu or in Linaro PPAs maintained by jcrigby, based on the Linaro Kernel tree with packaging and the Ubuntu stuff ("Sauce") merged in
- git://kernel.ubuntu.com/ubuntu/ubuntu-maverick.git linaro branch -- pretty much the same as jcrigby's tree maintained by the Ubuntu kernel team; it's mostly a copy of jcrigby's tree when it gets uploaded to Ubuntu, unless the Ubuntu kernel team has to do any minor adjustments/fixups before upload; it exists only because jcrigby can't upload and because /ubuntu is restricted to the official Ubuntu Kernel Team
So what problems / questions are we trying to solve?
- security support: Linaro isn't in the business of long-term security
support of its trees, however I understand that it wouldn't be a big problem to simply add the *Ubuntu* linux-linaro package and the kernel.ubuntu.com git tree to the list of packages/trees which get security updates from the Ubuntu Security Team, especially if the Ubuntu ARM Team moves to this package/tree as their base for some images
- for Linaro, the Ubuntu Sauce stuff doesn't add any much value and is
a distraction (causes more merge efforts, might cause extra bugs etc.)
Is this a fair summary? Did I miss anything?
I am not sure I understand the point of contention with the Ubuntu Sauce stuff; is it causing problems to Linaro right now? Linaro GCC is released in source form and then integrated in the Ubuntu gcc-4.x packages which have tons of patches added on top; this is not ideal for Linaro Toolchain WG, but it's part of the process to check whether bugs do apply to the pristine Linaro source, just like you need to test a pristine upstream GCC or Linux when reporting bugs upstream.
There are definitely things we could do to improve the Ubuntu Sauce:
- split this stuff more; e.g.:
- packaging goes in one tree (I think this is already split out?)
- patches which come from upstream or were acked upstream go into another tree
- patches which are Ubuntu specific such as AUFS go into one or multiple separate trees
- we could review the current sauce stuff and only merge in features
which are really needed for Linaro images and Ubuntu ARM images; aufs doesn't seem to be needed anymore for instance? Maybe this makes things more complex for little gain though
- we could stop merging patches from upstream from Ubuntu, and have
them flow in via Linaro instead; again, maybe this makes things more complex for little gain
My opinion is that the current approach is okay modulo two things:
- we should drop one of the two packaging trees; the
linaro / jcrigby versus kernel.ubuntu.com split is useless
- we could provide pristine kernel builds, built from the Linaro Kernel
directly and without any Ubuntu Sauce . in fact these exist already, they just aren't tested and they use a random config: http://hudson.dooz.org/ . if we want Linaro Kernel .debs instead of standalone zImage/uImage, we could do something like https://wiki.ubuntu.com/Kernel/MainlineBuilds
Proposed plan:
- Oliver/Ricardo to confirm with Ubuntu Security Team whether it's ok
to base Ubuntu ARM images on linux-linaro tree as constructed currently
I can't speak for the Ubuntu ARM folks but I believe their main concern was if I stopped including Ubuntu Sauce.
- John to request upload permissions for linux-linaro only and to
request commit rights to ubuntu/ubuntu-$release.git for the linaro branch only
The plan proposed at UDS was for Steve Langasek to take over the roll of linux-linaro upload sponsor. He would replace Tim G in this role. Perhaps we could try this for one cycle then consider the idea of me uploading after that.
- if someone cares about limiting the Ubuntu Sauce which goes into the
linux-linaro Ubuntu package which goes into Linaro images, then that someone ought to start discussion on splitting and limiting the Sauce which goes into the linaro branch with the Ubuntu Kernel Team; I don't think this fundamentally holds up anything though
The easiest way to include Ubuntu Sauce is to include all of it. It rarely causes merge conflicts and I can't think of an instance where it has caused breakage for linux-linaro so I suggest we just keep including it all. To include a subset would require someone to decide what subset and that would be extra work.
- if someone cares about providing better vanilla Linaro Kernel builds,
e.g. .debs, then that someone ought to start some spec on providing + testing these builds -- I'm happy to help here :-)
Cheers,
Loïc Minier
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On Mon, Nov 15, 2010, David Rusling wrote:
Good discussion. Stupid question - what is the Ubuntu sauce? I'll ask the kernel dudes in their meeting in two minutes...
Some Ubuntu specific patches are prefixed by "SAUCE" in their subject line / commit message, but the Ubuntu Sauce we refer to here is all the patches which get added on top to vanilla or BSP kernels when they are uploaded to Ubuntu. This includes things like AUFS support so that you can use aufs union mounts in live images, packaging, compcache, some out of tree drivers (see ubuntu/ directory in an Ubuntu kernel) etc.
On Mon, 15 Nov 2010, John Rigby wrote:
On Mon, Nov 15, 2010 at 4:28 AM, Loïc Minier loic.minier@ubuntu.com wrote:
Proposed plan: * Oliver/Ricardo to confirm with Ubuntu Security Team whether it's ok to base Ubuntu ARM images on linux-linaro tree as constructed currently
I can't speak for the Ubuntu ARM folks but I believe their main concern was if I stopped including Ubuntu Sauce.
[...]
The easiest way to include Ubuntu Sauce is to include all of it. It rarely causes merge conflicts and I can't think of an instance where it has caused breakage for linux-linaro so I suggest we just keep including it all.
Sure. So, this is therefore not a big deal, regardless of who is doing that merge (on the Linaro or Ubuntu side) right?
Hence my question again: what is that added effort people are afraid of? This must not be the Ubuntu sauce given John's experience.
I'm seeing some speculations wrt increased effort and would like to help finding solutions if there is actually a problem.
Nicolas
On Mon, Nov 15, 2010, Nicolas Pitre wrote:
I'm seeing some speculations wrt increased effort and would like to help finding solutions if there is actually a problem.
I'm seeing mainly the same thing: solutions looking for a problem. :)
I guess the only remaining chat is about security support
hi, Am Montag, den 15.11.2010, 08:53 -0700 schrieb John Rigby:
On Mon, Nov 15, 2010 at 4:28 AM, Loïc Minier loic.minier@ubuntu.com wrote:
Folks, I think this thread is circling a bit back to itself, perhaps summarizing where we stand and what problems we're trying to solve would help?
- Linaro integrates its kernel tree into Ubuntu for two reasons:
- because Linaro uses Ubuntu as a base to build its own derived images (out of Ubuntu)
- because Linaro wants its kernel shipped/available in distributions such as Ubuntu/MeeGo/whatever for mutual benefit of the distro and of Linaro. For instance, Ubuntu users could install this kernel instead of the official Ubuntu one, or Ubuntu could build images from this kernel (as proposed in the original email).
- there are currently the following *three* trees for the Ubuntu Linaro
kernel packages to happen (for maverick):
- git://git.linaro.org/kernel/linux-linaro-2.6.35.git -- upstreamish tree maintained by Nicolas, based on upstream git tree with patches relevant to Linaro merged in; the Linaro Kernel
- git://git.linaro.org/ubuntu/linux-linaro.git -- Ubuntu-ish tree for the linux-linaro source package in Ubuntu or in Linaro PPAs maintained by jcrigby, based on the Linaro Kernel tree with packaging and the Ubuntu stuff ("Sauce") merged in
- git://kernel.ubuntu.com/ubuntu/ubuntu-maverick.git linaro branch -- pretty much the same as jcrigby's tree maintained by the Ubuntu kernel team; it's mostly a copy of jcrigby's tree when it gets uploaded to Ubuntu, unless the Ubuntu kernel team has to do any minor adjustments/fixups before upload; it exists only because jcrigby can't upload and because /ubuntu is restricted to the official Ubuntu Kernel Team
So what problems / questions are we trying to solve?
- security support: Linaro isn't in the business of long-term security
support of its trees, however I understand that it wouldn't be a big problem to simply add the *Ubuntu* linux-linaro package and the kernel.ubuntu.com git tree to the list of packages/trees which get security updates from the Ubuntu Security Team, especially if the Ubuntu ARM Team moves to this package/tree as their base for some images
- for Linaro, the Ubuntu Sauce stuff doesn't add any much value and is
a distraction (causes more merge efforts, might cause extra bugs etc.)
Is this a fair summary? Did I miss anything?
I am not sure I understand the point of contention with the Ubuntu Sauce stuff; is it causing problems to Linaro right now? Linaro GCC is released in source form and then integrated in the Ubuntu gcc-4.x packages which have tons of patches added on top; this is not ideal for Linaro Toolchain WG, but it's part of the process to check whether bugs do apply to the pristine Linaro source, just like you need to test a pristine upstream GCC or Linux when reporting bugs upstream.
There are definitely things we could do to improve the Ubuntu Sauce:
- split this stuff more; e.g.:
- packaging goes in one tree (I think this is already split out?)
- patches which come from upstream or were acked upstream go into another tree
- patches which are Ubuntu specific such as AUFS go into one or multiple separate trees
- we could review the current sauce stuff and only merge in features
which are really needed for Linaro images and Ubuntu ARM images; aufs doesn't seem to be needed anymore for instance? Maybe this makes things more complex for little gain though
- we could stop merging patches from upstream from Ubuntu, and have
them flow in via Linaro instead; again, maybe this makes things more complex for little gain
My opinion is that the current approach is okay modulo two things:
- we should drop one of the two packaging trees; the
linaro / jcrigby versus kernel.ubuntu.com split is useless
- we could provide pristine kernel builds, built from the Linaro Kernel
directly and without any Ubuntu Sauce . in fact these exist already, they just aren't tested and they use a random config: http://hudson.dooz.org/ . if we want Linaro Kernel .debs instead of standalone zImage/uImage, we could do something like https://wiki.ubuntu.com/Kernel/MainlineBuilds
Proposed plan
- Oliver/Ricardo to confirm with Ubuntu Security Team whether it's ok
to base Ubuntu ARM images on linux-linaro tree as constructed currently
I can't speak for the Ubuntu ARM folks but I believe their main concern was if I stopped including Ubuntu Sauce.
right, that was one of my concerns, another was how much the kernels differ from BSP source we usually use for ubuntu images so that all on-board devices work out of the box.
then there is the question about ubuntu configs (which you answered) (since we try to keep our QA efforts low we expect the same or a close to same config to the ubuntu kernel in the arm kernels (i.e. a user needs to be able to plug in his DVB-T USB stick and get the same results in ubuntu arm as he gets on his ubuntu laptop))
my main concern though is the 18 month support timeframe which we provide for ubuntu images.
i think from the linaro side i got sufficient answers now, it seems we could use johns trees as a base for ubuntu images but would have to have someone from the ubuntu kernel team and the ubuntu security team for maintaining security and config alignment.
the situation in the kernel team wrt arm maintenance is just being sorted afaik, so i expect to get some info in this thread in the not to far future ...
ciao oli
On Sun, Nov 14, 2010 at 03:05:20AM -0200, Ricardo Salveti wrote:
On Thu, Nov 11, 2010 at 4:02 PM, Nicolas Pitre nicolas.pitre@canonical.com wrote:
On Tue, 9 Nov 2010, Oliver Grawert wrote:
On Thu, 11 Nov 2010, Ricardo Salveti wrote:
That's understandable. Now the question is why John is maintaining and packaging a tree that also incorporate the Ubuntu sauce on it?
I think that the main reason is that this was much easier to have a packaged initial release by simply piggybacking on the existing Ubuntu infrastructure. But John's tree and mine are still separate.
Ok, so there's nothing that guarantees that John will continue using the same Ubuntu infrastructure and sauce in the future.
I want to put a firm statement in here that Linaro are committed to supporting Ubuntu on ARM through our kernel work, and that if it's necessary for us to support the kernel maintenance process then we will do it -- so there is a firm guarantee from me that we'll always be open to working out what outputs you need.
I'd like to talk over the specific case of SAUCE patches, because I'm not entirely sure a) how much effort maintaining them is required and b) if we need to carry the Intel (and other arches) specific bits of SAUCE as well.
I'm getting the curious feeling that the above isn't clear to the people on this thread, so hopefully this is a step towards clarity.
On Mon, Nov 15, 2010 at 7:53 AM, Christian Robottom Reis kiko@canonical.com wrote:
On Sun, Nov 14, 2010 at 03:05:20AM -0200, Ricardo Salveti wrote:
On Thu, Nov 11, 2010 at 4:02 PM, Nicolas Pitre nicolas.pitre@canonical.com wrote:
On Tue, 9 Nov 2010, Oliver Grawert wrote:
On Thu, 11 Nov 2010, Ricardo Salveti wrote:
That's understandable. Now the question is why John is maintaining and packaging a tree that also incorporate the Ubuntu sauce on it?
I think that the main reason is that this was much easier to have a packaged initial release by simply piggybacking on the existing Ubuntu infrastructure. But John's tree and mine are still separate.
Ok, so there's nothing that guarantees that John will continue using the same Ubuntu infrastructure and sauce in the future.
I want to put a firm statement in here that Linaro are committed to supporting Ubuntu on ARM through our kernel work, and that if it's necessary for us to support the kernel maintenance process then we will do it -- so there is a firm guarantee from me that we'll always be open to working out what outputs you need.
I'd like to talk over the specific case of SAUCE patches, because I'm not entirely sure a) how much effort maintaining them is required and b) if we need to carry the Intel (and other arches) specific bits of SAUCE as well.
I'm getting the curious feeling that the above isn't clear to the people on this thread, so hopefully this is a step towards clarity.
Kiko,
Thanks for the clarification. You have answered my only question which was if Linaro engineering was willing to support the inclusion of Ubuntu Sauce.
John
For what it's worth, I agree with Kiko's statement. We have three stakeholders - internal use of the kernel by Linaro, external use by distributions (such as Ubuntu) and external use by community. We need to position ourselves appropriately...
Dave
On 15 Nov 2010, at 15:57, John Rigby wrote:
On Mon, Nov 15, 2010 at 7:53 AM, Christian Robottom Reis kiko@canonical.com wrote:
On Sun, Nov 14, 2010 at 03:05:20AM -0200, Ricardo Salveti wrote:
On Thu, Nov 11, 2010 at 4:02 PM, Nicolas Pitre nicolas.pitre@canonical.com wrote:
On Tue, 9 Nov 2010, Oliver Grawert wrote:
On Thu, 11 Nov 2010, Ricardo Salveti wrote:
That's understandable. Now the question is why John is maintaining and packaging a tree that also incorporate the Ubuntu sauce on it?
I think that the main reason is that this was much easier to have a packaged initial release by simply piggybacking on the existing Ubuntu infrastructure. But John's tree and mine are still separate.
Ok, so there's nothing that guarantees that John will continue using the same Ubuntu infrastructure and sauce in the future.
I want to put a firm statement in here that Linaro are committed to supporting Ubuntu on ARM through our kernel work, and that if it's necessary for us to support the kernel maintenance process then we will do it -- so there is a firm guarantee from me that we'll always be open to working out what outputs you need.
I'd like to talk over the specific case of SAUCE patches, because I'm not entirely sure a) how much effort maintaining them is required and b) if we need to carry the Intel (and other arches) specific bits of SAUCE as well.
I'm getting the curious feeling that the above isn't clear to the people on this thread, so hopefully this is a step towards clarity.
Kiko,
Thanks for the clarification. You have answered my only question which was if Linaro engineering was willing to support the inclusion of Ubuntu Sauce.
John
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
-
Christian Robottom Reis -
David Rusling -
Jamie Bennett -
John Rigby -
Loïc Minier -
Nicolas Pitre -
Nicolas Pitre -
Oliver Grawert -
Ricardo Salveti