On Tue, Aug 18, 2015 at 11:11:11AM +0100, Richard Purdie wrote: > On Tue, 2015-08-18 at 11:03 +0200, Martin Jansa wrote: > > On Thu, Aug 13, 2015 at 10:42:54AM +0200, Philip Balister wrote: > > > On 08/11/2015 10:46 PM, Otavio Salvador wrote: > > > > On Tue, Aug 11, 2015 at 5:36 PM, Burton, Ross <ross.bur...@intel.com> > > > > wrote: > > > >> > > > >> On 11 August 2015 at 16:46, Khem Raj <raj.k...@gmail.com> wrote: > > > >>> > > > >>> can we freeze this thread please. > > > >> > > > >> > > > >> Or more usefully, reboot it. Philip, you're turning into Koen! Alex, > > > >> if > > > >> someone on this list asks what Poky is, 99% of the time they're > > > >> trolling. > > > >> :) > > > >> > > > >> The original and unanswered question was "should oe-core continue to > > > >> maintain GPLv2 recipes where upstream has moved to GPLv3 or should > > > >> those > > > >> recipes move to a standalone layer" with various implied questions: > > > >> > > > >> - If the v2 recipes move to a separate layer, who own/maintains/tests > > > >> it? > > > >> - Should there be v2 recipes for every recipe that has moved to v3, or > > > >> only > > > >> (as is now) the "more-core" recipes (currently YP tests that > > > >> core-image-base > > > >> builds without GPLv3, nothing else more complicated) > > > >> - Should meta-gplv2 only contain recipes from oe-core, or all layers? > > > >> If > > > >> other layers decide to hold both v3 and v2 recipes (not that I'm aware > > > >> any > > > >> have), what makes oe-core special? > > > >> > > > >> I'm torn, Richard is torn. Neither of those are useful to forming a > > > >> decision. Does anyone else have any *useful* feedback? > > > > > > > > I think it is a matter of resource usage. > > > > > > > > Up to now, the GPLv2 maintenance has not been so hard and thus I would > > > > say for us to stay as is for now. We should revisit this for every > > > > release and review if it is time for split it or not. > > > > > > > > > > This would be a good time to remind us who the audience is for the gplv2 > > > recipes so we understand the amount of manpower behind their maintenance. > > > > > > My concern keeping then in core is that the commnunity who uses them > > > will reduce over time and they will bitrot. If that happens, we should > > > create a layer for them and remove them from core. > > > > It's still better to let them bitrot collectively in central layer than > > every OE user with this requirement maintaining old GPLv2 recipes in own > > layers and re-inventing the workarounds needed to build the rest of the > > system with latest upstream layers. > > I don't think anyone is suggesting we just abandon the idea and force > everyone to do this individually. The question is more about whether it > still makes sense to have the GPLv2 recipes in OE-Core or a separate > layer. It does also raise questions of scope, there are GPLv2 recipes > which OE-Core doesn't have and are not part of its stated policy (e.g. > screen being the current example). > > I do think its right to ask these questions although I'm still undecided > about what the best solution is...
Is it still true that autobuilder cannot test different sets of layers for different builds? It would be nice to see meta-gplv2 as separate layer, but tested and maintained as it is now inside oe-core (possibly with more help from outside especially if we can move some other recipes there as well). That way autobuilder can test meta-gplv2 layer only in non-GPLv3 builds and people who don't mind having GPLv3 components don't need to see "bit-rotten old versions" in proper oe-core. I was suggesting the same for sato in OEDAM (core-image built without meta-sato in one autobuilder job, then sato-image with meta-sato included in separate job), but IIRC there were some autobuilder limitations which prevented to use metadata layers like this (which seems very sad). Regards, -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
-- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core