* Additional / new BSP collection? @ 2011-07-27 5:21 Kumar Gala 2011-07-27 8:45 ` Richard Purdie 0 siblings, 1 reply; 13+ messages in thread From: Kumar Gala @ 2011-07-27 5:21 UTC (permalink / raw) To: Yocto discussion list Who is the best person to ask about adding new BSPs into yocto. What I mean by this is having a meta layer hosted on git.yoctoproject.org like meta-intel and the mechanics associated with this (getting new repo on git server, autobuilder support, webpage details, etc.). - k ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Additional / new BSP collection? 2011-07-27 5:21 Additional / new BSP collection? Kumar Gala @ 2011-07-27 8:45 ` Richard Purdie 2011-07-27 12:40 ` Kumar Gala 0 siblings, 1 reply; 13+ messages in thread From: Richard Purdie @ 2011-07-27 8:45 UTC (permalink / raw) To: Kumar Gala; +Cc: Yocto discussion list On Wed, 2011-07-27 at 00:21 -0500, Kumar Gala wrote: > Who is the best person to ask about adding new BSPs into yocto. What > I mean by this is having a meta layer hosted on git.yoctoproject.org > like meta-intel and the mechanics associated with this (getting new > repo on git server, autobuilder support, webpage details, etc.). This list is as good a place as any! :) Its relatively easy to arrange for a git repository. The main things we ask are that it has clearly defined maintainership (a clear maintainer and submission process) and a clear scope. Do you have any specific BSPs in mind? The wiki is available to host information and we can work out links on the website as the specific needs come up. Autobuilder support is something we need to figure out since its a finite resource but we can likely figure something out there once we understand what kind of BSPs we're talking about. Beth Flanagan <elizabeth.flanagan@intel.com> is the person who'd handle the mechanics of setting up the repository, the name is likely the hardest bit! Cheers, Richard ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Additional / new BSP collection? 2011-07-27 8:45 ` Richard Purdie @ 2011-07-27 12:40 ` Kumar Gala 2011-07-27 13:30 ` Bruce Ashfield 2011-07-27 13:50 ` Tom Zanussi 0 siblings, 2 replies; 13+ messages in thread From: Kumar Gala @ 2011-07-27 12:40 UTC (permalink / raw) To: Richard Purdie; +Cc: Yocto discussion list On Jul 27, 2011, at 3:45 AM, Richard Purdie wrote: > On Wed, 2011-07-27 at 00:21 -0500, Kumar Gala wrote: >> Who is the best person to ask about adding new BSPs into yocto. What >> I mean by this is having a meta layer hosted on git.yoctoproject.org >> like meta-intel and the mechanics associated with this (getting new >> repo on git server, autobuilder support, webpage details, etc.). > > This list is as good a place as any! :) > > Its relatively easy to arrange for a git repository. The main things we > ask are that it has clearly defined maintainership (a clear maintainer > and submission process) and a clear scope. Do you have any specific BSPs > in mind? Maintainership would be straight forward. Not sure about submissions process, what is done for meta-intel today? BSP would be for Freescale PowerPC SoC and the reference designs produced by FSL for them. > The wiki is available to host information and we can work out links on > the website as the specific needs come up. Autobuilder support is > something we need to figure out since its a finite resource but we can > likely figure something out there once we understand what kind of BSPs > we're talking about. > > Beth Flanagan <elizabeth.flanagan@intel.com> is the person who'd handle > the mechanics of setting up the repository, the name is likely the > hardest bit! meta-fsl-ppc ;) - k ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Additional / new BSP collection? 2011-07-27 12:40 ` Kumar Gala @ 2011-07-27 13:30 ` Bruce Ashfield 2011-07-27 13:52 ` Richard Purdie 2011-07-27 13:55 ` Kumar Gala 2011-07-27 13:50 ` Tom Zanussi 1 sibling, 2 replies; 13+ messages in thread From: Bruce Ashfield @ 2011-07-27 13:30 UTC (permalink / raw) To: Kumar Gala; +Cc: Yocto discussion list On 07/27/11 08:40, Kumar Gala wrote: > > On Jul 27, 2011, at 3:45 AM, Richard Purdie wrote: > >> On Wed, 2011-07-27 at 00:21 -0500, Kumar Gala wrote: >>> Who is the best person to ask about adding new BSPs into yocto. What >>> I mean by this is having a meta layer hosted on git.yoctoproject.org >>> like meta-intel and the mechanics associated with this (getting new >>> repo on git server, autobuilder support, webpage details, etc.). >> >> This list is as good a place as any! :) >> >> Its relatively easy to arrange for a git repository. The main things we >> ask are that it has clearly defined maintainership (a clear maintainer >> and submission process) and a clear scope. Do you have any specific BSPs >> in mind? > > Maintainership would be straight forward. Not sure about submissions process, what is done for meta-intel today? > > BSP would be for Freescale PowerPC SoC and the reference designs produced by FSL for them. Hi Kumar, As you know, I've been working on several kernel efforts around the FSL parts as well (in particular the ones that have enough pieces upstream to work out of the box). I definitely don't want to overlap in a way that doesn't create complimentary efforts. What are your current thoughts around kernels and the (nearly religious) kernel version question ? It would be great to get some alignment on features (-rt, tracing, boot, footprint reduction, etc, etc) and save some effort on maintenance and validation. Also if we want to create some yocto reference BSPs, having a kernel version and feature set match is important as well (i.e. what we've done for the intel ones). To that end, do you have an thoughts about using linux-yocto as a base to any BSP work ? That statement doesn't do it justice though, since when I say 'use linux-yocto as a base', it really means that linux-yocto uses your BSPs as an upstream/official reference and can pull support for them into branches, and have the configuration and other tooling get them any functionality that is being developed. No control over BSP content, or anything like this, is being suggested or asserted here. Just looking to all push in the same direction (embedded features and BSPs to upstream) and re-use the work of BSPs available in the community. If the base is the same (and hence kernel version), then this relationship and workflow is very simple. ... and as a bonus, if the workflow doesn't work easily, then there's a problem with it and we can work on something that is suitable (change tools, etc). Thanks, Bruce > >> The wiki is available to host information and we can work out links on >> the website as the specific needs come up. Autobuilder support is >> something we need to figure out since its a finite resource but we can >> likely figure something out there once we understand what kind of BSPs >> we're talking about. >> >> Beth Flanagan<elizabeth.flanagan@intel.com> is the person who'd handle >> the mechanics of setting up the repository, the name is likely the >> hardest bit! > > meta-fsl-ppc ;) > > - k > > _______________________________________________ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Additional / new BSP collection? 2011-07-27 13:30 ` Bruce Ashfield @ 2011-07-27 13:52 ` Richard Purdie 2011-07-27 13:55 ` Kumar Gala 1 sibling, 0 replies; 13+ messages in thread From: Richard Purdie @ 2011-07-27 13:52 UTC (permalink / raw) To: Bruce Ashfield; +Cc: Yocto discussion list On Wed, 2011-07-27 at 09:30 -0400, Bruce Ashfield wrote: > As you know, I've been working on several kernel efforts > around the FSL parts as well (in particular the ones that > have enough pieces upstream to work out of the box). I > definitely don't want to overlap in a way that doesn't > create complimentary efforts. > > What are your current thoughts around kernels and the > (nearly religious) kernel version question ? It would be > great to get some alignment on features (-rt, tracing, > boot, footprint reduction, etc, etc) and save some effort > on maintenance and validation. Also if we want to create > some yocto reference BSPs, having a kernel version and feature > set match is important as well (i.e. what we've done for > the intel ones). > > To that end, do you have an thoughts about using linux-yocto > as a base to any BSP work ? That statement doesn't do it > justice though, since when I say 'use linux-yocto as a base', > it really means that linux-yocto uses your BSPs as an > upstream/official reference and can pull support for them > into branches, and have the configuration and other tooling > get them any functionality that is being developed. > > No control over BSP content, or anything like this, is being > suggested or asserted here. Just looking to all push in the > same direction (embedded features and BSPs to upstream) and > re-use the work of BSPs available in the community. If the > base is the same (and hence kernel version), then this relationship > and workflow is very simple. > > ... and as a bonus, if the workflow doesn't work easily, then > there's a problem with it and we can work on something that > is suitable (change tools, etc). So just to put what Bruce says into other words, there isn't any hard requirement to use linux-yocto but we are asking people to try it and if it doesn't work, at least tell us why. I understand transitions and new ways of working take time and that meta-fsl-ppc might be enough of a step at first without the linux-yocto complications. That is fine but please do keep it in mind. Cheers, Richard ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Additional / new BSP collection? 2011-07-27 13:30 ` Bruce Ashfield 2011-07-27 13:52 ` Richard Purdie @ 2011-07-27 13:55 ` Kumar Gala 2011-07-27 14:23 ` Richard Purdie 1 sibling, 1 reply; 13+ messages in thread From: Kumar Gala @ 2011-07-27 13:55 UTC (permalink / raw) To: Bruce Ashfield; +Cc: Yocto discussion list > Hi Kumar, > > As you know, I've been working on several kernel efforts > around the FSL parts as well (in particular the ones that > have enough pieces upstream to work out of the box). I > definitely don't want to overlap in a way that doesn't > create complimentary efforts. > > What are your current thoughts around kernels and the > (nearly religious) kernel version question ? It would be > great to get some alignment on features (-rt, tracing, > boot, footprint reduction, etc, etc) and save some effort > on maintenance and validation. Also if we want to create > some yocto reference BSPs, having a kernel version and feature > set match is important as well (i.e. what we've done for > the intel ones). > > To that end, do you have an thoughts about using linux-yocto > as a base to any BSP work ? That statement doesn't do it > justice though, since when I say 'use linux-yocto as a base', > it really means that linux-yocto uses your BSPs as an > upstream/official reference and can pull support for them > into branches, and have the configuration and other tooling > get them any functionality that is being developed. > > No control over BSP content, or anything like this, is being > suggested or asserted here. Just looking to all push in the > same direction (embedded features and BSPs to upstream) and > re-use the work of BSPs available in the community. If the > base is the same (and hence kernel version), then this relationship > and workflow is very simple. > > ... and as a bonus, if the workflow doesn't work easily, then > there's a problem with it and we can work on something that > is suitable (change tools, etc). > > Thanks, > > Bruce What I'm envisioning as a start is we'd offer a meta layer on yocto sites for the upstream supported boards & feature set. I'm still looking at what we do for a FSL delivered BSP (via freescale.com) that would be based on that. My initial concerns are that the yocto community will probably move and change things too frequently for our customer base (kernel version, toolchain version, etc). Thus my thinking of de-coupling the two a bit. The yocto versions of BSPs would track yocto development. The FSL delivered BSPs would probably track to an older yocto version & slower update cycle. - k ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Additional / new BSP collection? 2011-07-27 13:55 ` Kumar Gala @ 2011-07-27 14:23 ` Richard Purdie 2011-07-27 14:58 ` Bruce Ashfield 0 siblings, 1 reply; 13+ messages in thread From: Richard Purdie @ 2011-07-27 14:23 UTC (permalink / raw) To: Kumar Gala; +Cc: Yocto discussion list On Wed, 2011-07-27 at 08:55 -0500, Kumar Gala wrote: > > Hi Kumar, > > > > As you know, I've been working on several kernel efforts > > around the FSL parts as well (in particular the ones that > > have enough pieces upstream to work out of the box). I > > definitely don't want to overlap in a way that doesn't > > create complimentary efforts. > > > > What are your current thoughts around kernels and the > > (nearly religious) kernel version question ? It would be > > great to get some alignment on features (-rt, tracing, > > boot, footprint reduction, etc, etc) and save some effort > > on maintenance and validation. Also if we want to create > > some yocto reference BSPs, having a kernel version and feature > > set match is important as well (i.e. what we've done for > > the intel ones). > > > > To that end, do you have an thoughts about using linux-yocto > > as a base to any BSP work ? That statement doesn't do it > > justice though, since when I say 'use linux-yocto as a base', > > it really means that linux-yocto uses your BSPs as an > > upstream/official reference and can pull support for them > > into branches, and have the configuration and other tooling > > get them any functionality that is being developed. > > > > No control over BSP content, or anything like this, is being > > suggested or asserted here. Just looking to all push in the > > same direction (embedded features and BSPs to upstream) and > > re-use the work of BSPs available in the community. If the > > base is the same (and hence kernel version), then this relationship > > and workflow is very simple. > > > > ... and as a bonus, if the workflow doesn't work easily, then > > there's a problem with it and we can work on something that > > is suitable (change tools, etc). > > > > Thanks, > > > > Bruce > > What I'm envisioning as a start is we'd offer a meta layer on yocto > sites for the upstream supported boards & feature set. > > I'm still looking at what we do for a FSL delivered BSP (via > freescale.com) that would be based on that. My initial concerns are > that the yocto community will probably move and change things too > frequently for our customer base (kernel version, toolchain version, > etc). Thus my thinking of de-coupling the two a bit. The yocto > versions of BSPs would track yocto development. The FSL delivered > BSPs would probably track to an older yocto version & slower update > cycle. Just for reference, this is exactly what meta-intel intends to do. The released versions of the code there are based on a specific release of Yocto/OE-Core. When new BSPs are developed they are likely developed on the last stable release of Yocto, not bleeding edge master unless there is some pressing reason to do so. This is where we start to see major benefits of the layer model. Cheers, Richard ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Additional / new BSP collection? 2011-07-27 14:23 ` Richard Purdie @ 2011-07-27 14:58 ` Bruce Ashfield 0 siblings, 0 replies; 13+ messages in thread From: Bruce Ashfield @ 2011-07-27 14:58 UTC (permalink / raw) To: Richard Purdie; +Cc: Yocto discussion list On 07/27/11 10:23, Richard Purdie wrote: > On Wed, 2011-07-27 at 08:55 -0500, Kumar Gala wrote: >>> Hi Kumar, >>> >>> As you know, I've been working on several kernel efforts >>> around the FSL parts as well (in particular the ones that >>> have enough pieces upstream to work out of the box). I >>> definitely don't want to overlap in a way that doesn't >>> create complimentary efforts. >>> >>> What are your current thoughts around kernels and the >>> (nearly religious) kernel version question ? It would be >>> great to get some alignment on features (-rt, tracing, >>> boot, footprint reduction, etc, etc) and save some effort >>> on maintenance and validation. Also if we want to create >>> some yocto reference BSPs, having a kernel version and feature >>> set match is important as well (i.e. what we've done for >>> the intel ones). >>> >>> To that end, do you have an thoughts about using linux-yocto >>> as a base to any BSP work ? That statement doesn't do it >>> justice though, since when I say 'use linux-yocto as a base', >>> it really means that linux-yocto uses your BSPs as an >>> upstream/official reference and can pull support for them >>> into branches, and have the configuration and other tooling >>> get them any functionality that is being developed. >>> >>> No control over BSP content, or anything like this, is being >>> suggested or asserted here. Just looking to all push in the >>> same direction (embedded features and BSPs to upstream) and >>> re-use the work of BSPs available in the community. If the >>> base is the same (and hence kernel version), then this relationship >>> and workflow is very simple. >>> >>> ... and as a bonus, if the workflow doesn't work easily, then >>> there's a problem with it and we can work on something that >>> is suitable (change tools, etc). >>> >>> Thanks, >>> >>> Bruce >> >> What I'm envisioning as a start is we'd offer a meta layer on yocto >> sites for the upstream supported boards& feature set. >> >> I'm still looking at what we do for a FSL delivered BSP (via >> freescale.com) that would be based on that. My initial concerns are >> that the yocto community will probably move and change things too >> frequently for our customer base (kernel version, toolchain version, >> etc). Thus my thinking of de-coupling the two a bit. The yocto >> versions of BSPs would track yocto development. The FSL delivered >> BSPs would probably track to an older yocto version& slower update >> cycle. > > Just for reference, this is exactly what meta-intel intends to do. The > released versions of the code there are based on a specific release of > Yocto/OE-Core. When new BSPs are developed they are likely developed on > the last stable release of Yocto, not bleeding edge master unless there > is some pressing reason to do so. Most definitely. Having some sort of alignment on the kernel versions is nice, but we definitely don't expect all BSPs to follow every new kernel. And like Richard said, the model you are thinking about makes a lot of sense. If we nominate some important BSPs (one of my post 1.1 tasks), and they get into the yocto-kernel tree, you have the advantage that when I uprev the kernel they largely get hauled along for the ride. Cheers, Brice > > This is where we start to see major benefits of the layer model. > > Cheers, > > Richard > > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Additional / new BSP collection? 2011-07-27 12:40 ` Kumar Gala 2011-07-27 13:30 ` Bruce Ashfield @ 2011-07-27 13:50 ` Tom Zanussi 2011-07-27 13:53 ` Kumar Gala 1 sibling, 1 reply; 13+ messages in thread From: Tom Zanussi @ 2011-07-27 13:50 UTC (permalink / raw) To: Kumar Gala; +Cc: Yocto discussion list On Wed, 2011-07-27 at 05:40 -0700, Kumar Gala wrote: > On Jul 27, 2011, at 3:45 AM, Richard Purdie wrote: > > > On Wed, 2011-07-27 at 00:21 -0500, Kumar Gala wrote: > >> Who is the best person to ask about adding new BSPs into yocto. What > >> I mean by this is having a meta layer hosted on git.yoctoproject.org > >> like meta-intel and the mechanics associated with this (getting new > >> repo on git server, autobuilder support, webpage details, etc.). > > > > This list is as good a place as any! :) > > > > Its relatively easy to arrange for a git repository. The main things we > > ask are that it has clearly defined maintainership (a clear maintainer > > and submission process) and a clear scope. Do you have any specific BSPs > > in mind? > > Maintainership would be straight forward. Not sure about submissions process, what is done for meta-intel today? > Hi Kumar, For meta-intel, it's pretty simple and is summarized by this blurb from the meta-intel MAINTAINERS file: "Please submit any patches against meta-intel BSPs to the Yocto mailing list (yocto@yoctoproject.org)." Basically, new patches get submitted to the mailing list, go through the standard on-list comment and review process, and then get pulled into master by whoever maintains the BSP when everything looks good. Hope that helps, Tom > BSP would be for Freescale PowerPC SoC and the reference designs produced by FSL for them. > > > The wiki is available to host information and we can work out links on > > the website as the specific needs come up. Autobuilder support is > > something we need to figure out since its a finite resource but we can > > likely figure something out there once we understand what kind of BSPs > > we're talking about. > > > > Beth Flanagan <elizabeth.flanagan@intel.com> is the person who'd handle > > the mechanics of setting up the repository, the name is likely the > > hardest bit! > > meta-fsl-ppc ;) > > - k > > _______________________________________________ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Additional / new BSP collection? 2011-07-27 13:50 ` Tom Zanussi @ 2011-07-27 13:53 ` Kumar Gala 2011-07-27 14:06 ` Tom Zanussi 0 siblings, 1 reply; 13+ messages in thread From: Kumar Gala @ 2011-07-27 13:53 UTC (permalink / raw) To: Tom Zanussi; +Cc: Yocto discussion list On Jul 27, 2011, at 8:50 AM, Tom Zanussi wrote: > Hi Kumar, > > For meta-intel, it's pretty simple and is summarized by this blurb from > the meta-intel MAINTAINERS file: > > "Please submit any patches against meta-intel BSPs to the Yocto mailing > list (yocto@yoctoproject.org)." > > Basically, new patches get submitted to the mailing list, go through the > standard on-list comment and review process, and then get pulled into > master by whoever maintains the BSP when everything looks good. > > Hope that helps, > > Tom Ok, same model would work for meta-fsl-ppc. The one question I have is if it make sense to migrate such patches over to 'yocto-bsp@yoctoproject.org' list. - k ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Additional / new BSP collection? 2011-07-27 13:53 ` Kumar Gala @ 2011-07-27 14:06 ` Tom Zanussi 2011-07-27 14:13 ` Kumar Gala 2011-07-27 14:33 ` Cherry, John 0 siblings, 2 replies; 13+ messages in thread From: Tom Zanussi @ 2011-07-27 14:06 UTC (permalink / raw) To: Kumar Gala; +Cc: Yocto discussion list On Wed, 2011-07-27 at 06:53 -0700, Kumar Gala wrote: > On Jul 27, 2011, at 8:50 AM, Tom Zanussi wrote: > > > Hi Kumar, > > > > For meta-intel, it's pretty simple and is summarized by this blurb from > > the meta-intel MAINTAINERS file: > > > > "Please submit any patches against meta-intel BSPs to the Yocto mailing > > list (yocto@yoctoproject.org)." > > > > Basically, new patches get submitted to the mailing list, go through the > > standard on-list comment and review process, and then get pulled into > > master by whoever maintains the BSP when everything looks good. > > > > Hope that helps, > > > > Tom > > Ok, same model would work for meta-fsl-ppc. The one question I have is if it make sense to migrate such patches over to 'yocto-bsp@yoctoproject.org' list. > Hmm, I completely forgot about that list, and apparently everybody else has too (no messages in it). It's also not linked to from anywhere on the Yocto site that I can see e.g. Community | Mailing Lists. Personally I'd prefer less fragmentation of lists, and think it would get better review and exposure on the yocto list, but if it makes more sense to people to start using the yocto-bsp list, fine with me... Tom > - k ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Additional / new BSP collection? 2011-07-27 14:06 ` Tom Zanussi @ 2011-07-27 14:13 ` Kumar Gala 2011-07-27 14:33 ` Cherry, John 1 sibling, 0 replies; 13+ messages in thread From: Kumar Gala @ 2011-07-27 14:13 UTC (permalink / raw) To: Tom Zanussi; +Cc: Yocto discussion list On Jul 27, 2011, at 9:06 AM, Tom Zanussi wrote: > On Wed, 2011-07-27 at 06:53 -0700, Kumar Gala wrote: >> On Jul 27, 2011, at 8:50 AM, Tom Zanussi wrote: >> >>> Hi Kumar, >>> >>> For meta-intel, it's pretty simple and is summarized by this blurb from >>> the meta-intel MAINTAINERS file: >>> >>> "Please submit any patches against meta-intel BSPs to the Yocto mailing >>> list (yocto@yoctoproject.org)." >>> >>> Basically, new patches get submitted to the mailing list, go through the >>> standard on-list comment and review process, and then get pulled into >>> master by whoever maintains the BSP when everything looks good. >>> >>> Hope that helps, >>> >>> Tom >> >> Ok, same model would work for meta-fsl-ppc. The one question I have is if it make sense to migrate such patches over to 'yocto-bsp@yoctoproject.org' list. >> > > Hmm, I completely forgot about that list, and apparently everybody else > has too (no messages in it). It's also not linked to from anywhere on > the Yocto site that I can see e.g. Community | Mailing Lists. > > Personally I'd prefer less fragmentation of lists, and think it would > get better review and exposure on the yocto list, but if it makes more > sense to people to start using the yocto-bsp list, fine with me... > > Tom > >> - k > I'm good w/just using the main yocto list for now until traffic gets to a point we think it makes sense to split it off - k ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Additional / new BSP collection? 2011-07-27 14:06 ` Tom Zanussi 2011-07-27 14:13 ` Kumar Gala @ 2011-07-27 14:33 ` Cherry, John 1 sibling, 0 replies; 13+ messages in thread From: Cherry, John @ 2011-07-27 14:33 UTC (permalink / raw) To: Tom Zanussi, Kumar Gala; +Cc: Yocto discussion list > -----Original Message----- > From: yocto-bounces@yoctoproject.org [mailto:yocto- > bounces@yoctoproject.org] On Behalf Of Tom Zanussi > Sent: Wednesday, July 27, 2011 7:07 AM > To: Kumar Gala > Cc: Yocto discussion list > Subject: Re: [yocto] Additional / new BSP collection? > > On Wed, 2011-07-27 at 06:53 -0700, Kumar Gala wrote: > > On Jul 27, 2011, at 8:50 AM, Tom Zanussi wrote: > > > > > Hi Kumar, > > > > > > For meta-intel, it's pretty simple and is summarized by this blurb > from > > > the meta-intel MAINTAINERS file: > > > > > > "Please submit any patches against meta-intel BSPs to the Yocto > mailing > > > list (yocto@yoctoproject.org)." > > > > > > Basically, new patches get submitted to the mailing list, go > through the > > > standard on-list comment and review process, and then get pulled > into > > > master by whoever maintains the BSP when everything looks good. > > > > > > Hope that helps, > > > > > > Tom > > > > Ok, same model would work for meta-fsl-ppc. The one question I have > is if it make sense to migrate such patches over to 'yocto- > bsp@yoctoproject.org' list. > > > > Hmm, I completely forgot about that list, and apparently everybody else > has too (no messages in it). It's also not linked to from anywhere on > the Yocto site that I can see e.g. Community | Mailing Lists. I think the yocto-bsp list was set up in anticipation of a BSP special interest group. As far as I know, it is not being used yet. > > Personally I'd prefer less fragmentation of lists, and think it would > get better review and exposure on the yocto list, but if it makes more > sense to people to start using the yocto-bsp list, fine with me... > > Tom > > > - k > > > _______________________________________________ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2011-07-27 14:58 UTC | newest] Thread overview: 13+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-07-27 5:21 Additional / new BSP collection? Kumar Gala 2011-07-27 8:45 ` Richard Purdie 2011-07-27 12:40 ` Kumar Gala 2011-07-27 13:30 ` Bruce Ashfield 2011-07-27 13:52 ` Richard Purdie 2011-07-27 13:55 ` Kumar Gala 2011-07-27 14:23 ` Richard Purdie 2011-07-27 14:58 ` Bruce Ashfield 2011-07-27 13:50 ` Tom Zanussi 2011-07-27 13:53 ` Kumar Gala 2011-07-27 14:06 ` Tom Zanussi 2011-07-27 14:13 ` Kumar Gala 2011-07-27 14:33 ` Cherry, John
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.