Re: [OE-core] meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]
On Fri, Aug 07, 2015 at 03:26:45PM +0300, Alexander Kanavin wrote: On 08/07/2015 12:17 PM, Philip Balister wrote: Thanks Khem. I also do not agree that we lack a self-sustaining community. OpenEmbedded has functioned independently for far longer than the Yocto Project has existed. By 'self-sustaining' I mean 'being able to continuously produce quality work'. Looking at layers in meta-openembedded, not all of them are of high quality. Meta-gnome in particular is badly out of date, because no one wants to maintain it properly. If oe-core starts taking a lot more volunteer contributions, and the same thing happens (a volunteer contributes a large set of recipes, then disappears), what is supposed to happen then? Having latest version of all recipes is good thing, but it's not the best quality indicator. In meta-oe and oe-classic package upgrades were usually done by people who were actively using those recipes and only when the new version introduced something they really needed or wanted. Still it was causing new issues, because nobody can test every combination how something can be used. Now we see a lot of upgrades in oe-core which are done by people just because package upgrade report says it's possible and the upgrade is tested mostly by autobuilder (which doesn't exersize any extra layers and runtime-test coverage is very low) - so in the end many of these good to have upgrades are breaking some other components which aren't upgraded so often or breaking/changing runtime behavior and only couple months later someone who is actually using them will report that. 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
Re: [OE-core] meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]
On 08/18/2015 10:54 AM, Martin Jansa wrote: Now we see a lot of upgrades in oe-core which are done by people just because package upgrade report says it's possible and the upgrade is tested mostly by autobuilder (which doesn't exersize any extra layers and runtime-test coverage is very low) - so in the end many of these good to have upgrades are breaking some other components which aren't upgraded so often or breaking/changing runtime behavior and only couple months later someone who is actually using them will report that. The alternative isn't great either. Older, out-of-date software tends to require more effort to backport security fixes and prevent bitrot (maybe as much effort as would be spent simply updating it to latest versions). Or if no one does the backporting then you have an insecure software stack. Then, when gigantic, must-have updates happen, they take forever to prepare, review, (rebase, update, review)* and merge, they're met with more resistance, and cause even more breakage and pain in the other layers than if the same thing would have been achieved via small, incremental updates. Test automation is being worked on, so when that is in place, then rolling, small updates approach will be clearly superior. Regards, Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]
On Tue, 2015-08-18 at 13:16 +0200, Martin Jansa wrote: 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). I think things are improving in this area, it can handle simple layer changes. That said, I'm nervous about touching the autobuilder config too much as even simpler changes to the autobuilder configuration tend to have issues which cause massive headaches trying to keep patches moving. I don't think the shear amount of pain we're suffering at the moment is particularly visible to people :/. Separating out sato from the core, particularly within the tests is likely to be quite some work. Its certainly doable, the question is whether its a priority with the resources available and to put it simply, there isn't the bandwidth/resources. It would also likely mean we end up building twice the quantity of builds with and without sato which we simply don't have the autobuilder resources for (or we accept testing cycles double). Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]
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
Re: [OE-core] meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]
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. -- 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
Re: [OE-core] meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]
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. Philip -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]
On 8/13/15 3:42 AM, 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. I can only speak for the customers I know of directly. They are: * People whose lawyers tell them they can't use GPLv3, for no other reason that FUD. (This is diminishing.) The follow are all around the 'TiVo-ization clause' concerns... * People in the medical space - Some devices if modified have serious safety concerns. So they want to be able to lock down the device and must due so to get things like FDA certification. * People in the automotive space (IVI, etc) - In some countries if a user modifies the device, due to the automaker permitting modifications, the automake suddenly becomes liable for the users changes. This is a pretty nasty catch in their laws. So the automakes want the ability again to lock down the device to prevent liability issues, as well as for potential safety concerns. * Aeronautics - I've only talked to a few people on this, so I don't know if it is accurate or not.. but again the issue is for FAA certification and similar they can't permit changes to various flight systems. If they permit a user to modify the device it may fail FAA certification. * Consumer Electronics - Some devices may be built in such a way that the designer does not want to permit the user from modifying the device. This is generally around things like DRM, or devices that have physical components (like tape control) that can be damaged due to improper control. - DRM if implemented in software can be a concern simply due to contractural issues.. - Physical device issues are all about warranty concerns. (Personally I think it's a red herring, but I've heard the concern on a number of devices from a few large manufacturers.) 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. I think GPLv2 is a limited set of the community, but I also think that it's an important set. It removes some of the traditional embedded Linux concerns from various markets. As for bitrot, for the existing components, I don't see this as a concern for the next few years at least. There is still a health (commercial) community using these components regularly, and worst case fixes are being developed and sent back to the community via OSVs and integrators. --Mark Philip -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]
On Thu, Aug 13, 2015 at 1:42 AM, Philip Balister phi...@balister.org 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. As others have also mentioned, there are certain classes of product (set-top boxes, automotive, medical, etc, etc) where secure boot and signed firmware images are a non-negotiable requirement. I don't see these classes of product going away any time soon, so it's hard to see the overall need for GPLv3-free embedded distros reducing. Some forward-thinking companies making these types of products are already switching to OE [1], but I guess the majority are still using legacy build environments and home-grown distros. Since these home-grown distros typically take a conservative approach to updating packages, the pain of sticking with older, pre-GPLv3 versions might not be felt very strongly yet. It will inevitably increase over time though and as it does there's going to be a growing number of developers working to maintain pre-GPLv3 versions (or working to switch to replacement packages with more permissive licenses). [1] http://www.slideshare.net/linaroorg/hkg15506-comcast-lessons-learned-from-migrating-the-rdk-code-base-to-the-openembeddedyocto-build-framework Philip -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]
On 8/11/15 3:36 PM, Burton, Ross wrote: On 11 August 2015 at 16:46, Khem Raj raj.k...@gmail.com mailto: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? Not sure how useful, but I can give what I remember as the history behind the GPLv2 work and my opinion as someone who has a lot of customers who don't want GPLv3 software on the target. Originally when this work was proposed (keeping older GPLv2 software in oe-core) the decision was made to keep a small core set of components. Things that the system wouldn't work without. I.e. coreutils, util-linux, gettext, etc.. I believe the bar was set just above core-image-minimal. Anything more then a small (busybox or discrete component) filesystem can require GPLv3 and at that point it's up to others to figure out how they want to deal with it. So based on the original theory here, parted (GPLv2) is right on the edge of small system or not. It wasn't originally included because were were not considering (embedded) systems that would have to be partition at runtime. (I did much of the original scoping for GPLv2 components... so at least that is why I left it off the list.) (opinion part) That however doesn't mean we have to just reject this as being out of scope, but I think it does push this more toward the not part of oe-core side of things. As someone who has a lot of customers that need non-GPLv2 components for various reasons, I would like an ecosystem for components above and beyond what is allowed into oe-core for contributed things like this older version of parted, but not concern is bit-rot. If it's in oe-core, it's (generally) being used and tested and we get discussions like this... if it's shifted off into another layer, that layer needs a maintainer or it's going to fall away. So I honestly don't want to move any of the existing GPLv2 items out of oe-core at this time.. possibly someday, but not now. Additional (old) GPLv2 versions really should be able to go somewhere and be shared, but I don't have a good idea as to where. This is an opportunity for a new layer to focus on non-oe-core GPLv2 or possibly a layer as part of meta-openembedded. (I'm not sure though Martin wants to take on that, even if it turns out to be minimal additional work.) (rant part) In the end for people who can't use GPLv3 for whatever reason, there really should be a coordinated effort to either update old versions of software (GPLv2) or simply replace the items with BSD/MIT or other appropriately sourced and licensed code. I just don't see much coordination beyond oe-core (and the Yocto Project) for this kind of work -- and the most I'm willing to sign up for is to keep what we have functional for as long as my customers need it. --Mark Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]
On Aug 11, 2015, at 1:36 PM, Burton, Ross ross.bur...@intel.com wrote: On 11 August 2015 at 16:46, Khem Raj raj.k...@gmail.com mailto: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. :) this ml it might be. But I interact with many folks who hear of it for first time and in general its quite confusing when you explain this to someone new. They get confused when they see yocto 1.8 and then poky 13.0, bitbake 1.26 and oe-core branched with codenames, poky distro layer is called meta-yocto and it also has BSPs in same repo, if you think from their POV its very confusing for some one new who is trying to get some understanding of this all. may be we can do without some of these now a days. but thats discussion for another day :) 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? motivated enough to use OE some folks might come up but it won’t be same, at this time I know it gets more users for OE may be less developers but then look at patches to these components has come from users turned developers. We should also look into the case why glibc folded the secondary class architectures which were maintained in ports repository into glibc proper. - 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? These are pertinent questions that I have raised earlier on thread that can cause more confusion to end user, but i think if we keep the check for choosing GPLv2 only packages in OE-Core and move these recipes to something like meta-legacy or something like that and not associate it with license name then we don’t have to worry about above questions. I'm torn, Richard is torn. Neither of those are useful to forming a decision. Does anyone else have any *useful* feedback? however it can be left in there if its not causing a lot of maintenance burden since it still serves a purpose downstream. Ross signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]
On 08/10/2015 10:15 PM, Philip Balister wrote: This is perfectly fine with me. However, the subject has been whether the scope of *oe-core/poky* can be expanded without compromising What is Poky? Uhm... http://git.yoctoproject.org/cgit/cgit.cgi/poky/about/ Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]
On Tue, Aug 11, 2015 at 6:26 AM, Alexander Kanavin alexander.kana...@linux.intel.com wrote: On 08/10/2015 10:15 PM, Philip Balister wrote: This is perfectly fine with me. However, the subject has been whether the scope of *oe-core/poky* can be expanded without compromising What is Poky? Uhm... http://git.yoctoproject.org/cgit/cgit.cgi/poky/about/ can we freeze this thread please. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]
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? Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]
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. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]
On 08/10/2015 02:13 PM, Alexander Kanavin wrote: On 08/08/2015 08:09 PM, Philip Balister wrote: By 'self-sustaining' I mean 'being able to continuously produce quality work'. Looking at layers in meta-openembedded, not all of them are of high quality. Meta-gnome in particular is badly out of date, because no one wants to maintain it properly. If oe-core starts taking a lot more volunteer contributions, and the same thing happens (a volunteer contributes a large set of recipes, then disappears), what is supposed to happen then? You are missing the point. We now use layers to segregate sets of recipes o stuff that is not interesting to many people and becomes obsolete may decline without compromising heavily used layers. This is all part of the evolution of OpenEmbedded over many, many years. If people lose interest in meta-gplv2, then so be it. This is perfectly fine with me. However, the subject has been whether the scope of *oe-core/poky* can be expanded without compromising What is Poky? Philip quality. I'm not sure at which point it got confused with general OE, so I can only refer you back to several emails up this thread: http://lists.openembedded.org/pipermail/openembedded-core/2015-July/108037.html http://lists.openembedded.org/pipermail/openembedded-core/2015-July/108167.html http://lists.openembedded.org/pipermail/openembedded-core/2015-July/108208.html Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]
On 08/08/2015 08:09 PM, Philip Balister wrote: By 'self-sustaining' I mean 'being able to continuously produce quality work'. Looking at layers in meta-openembedded, not all of them are of high quality. Meta-gnome in particular is badly out of date, because no one wants to maintain it properly. If oe-core starts taking a lot more volunteer contributions, and the same thing happens (a volunteer contributes a large set of recipes, then disappears), what is supposed to happen then? You are missing the point. We now use layers to segregate sets of recipes o stuff that is not interesting to many people and becomes obsolete may decline without compromising heavily used layers. This is all part of the evolution of OpenEmbedded over many, many years. If people lose interest in meta-gplv2, then so be it. This is perfectly fine with me. However, the subject has been whether the scope of *oe-core/poky* can be expanded without compromising quality. I'm not sure at which point it got confused with general OE, so I can only refer you back to several emails up this thread: http://lists.openembedded.org/pipermail/openembedded-core/2015-July/108037.html http://lists.openembedded.org/pipermail/openembedded-core/2015-July/108167.html http://lists.openembedded.org/pipermail/openembedded-core/2015-July/108208.html Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]
On 08/07/2015 02:26 PM, Alexander Kanavin wrote: On 08/07/2015 12:17 PM, Philip Balister wrote: Thanks Khem. I also do not agree that we lack a self-sustaining community. OpenEmbedded has functioned independently for far longer than the Yocto Project has existed. By 'self-sustaining' I mean 'being able to continuously produce quality work'. Looking at layers in meta-openembedded, not all of them are of high quality. Meta-gnome in particular is badly out of date, because no one wants to maintain it properly. If oe-core starts taking a lot more volunteer contributions, and the same thing happens (a volunteer contributes a large set of recipes, then disappears), what is supposed to happen then? You are missing the point. We now use layers to segregate sets of recipes o stuff that is not interesting to many people and becomes obsolete may decline without compromising heavily used layers. This is all part of the evolution of OpenEmbedded over many, many years. If people lose interest in meta-gplv2, then so be it. Philip Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]
On Fri, Jul 31, 2015 at 4:41 AM, Alexander Kanavin alexander.kana...@linux.intel.com wrote: My issue here is quality control. Someone still has to review the work of those volunteer developers, and take action when they fail to take action. Yocto at the moment does not have such a self-sustaining community process - it all still goes through 'core' oe-core developers, and those developers can't have any more workload. its a delicate balance of usability of target audience as well. If you make it high quality but ignore real use case of end users you lose and you lose otherway around too. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]
On Sat, Jul 11, 2015 at 12:57 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: As someone has volunteered to maintain the pre-GPLv3 parted recipe (and I'll volunteer as a secondary maintainer, if that helps) hopefully there would not be a serious maintenance burden on anyone who doesn't have an interest in the older version. This does touch on something I have wondered about for a while, which is whether the time has come to move the GPLv2 pieces to their own layer and possibly their own maintainership. Obviously there are pros and cons to doing that. Thoughts? interesting case, although, I know lot of real usecases of OE which disable GPLv3 distro wide and in fact is considered a strong point for its users, if we were to maintain them in separate layer this would be fine but we will send a wrong message to users since we have to clarify its not all gpl2 code but only the code which is old and has moved to v3 etc. can cause confusion, OE's users are a bit different than desktop distros. Now if we were talking about moving all of GPL recipes to layer of its own thats a separate case and may be more useful but is that possible ? I suggest to do a survey of its use before dropping it out. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]
On 08/07/2015 08:12 AM, Khem Raj wrote: On Fri, Jul 31, 2015 at 4:41 AM, Alexander Kanavin alexander.kana...@linux.intel.com wrote: My issue here is quality control. Someone still has to review the work of those volunteer developers, and take action when they fail to take action. Yocto at the moment does not have such a self-sustaining community process - it all still goes through 'core' oe-core developers, and those developers can't have any more workload. its a delicate balance of usability of target audience as well. If you make it high quality but ignore real use case of end users you lose and you lose otherway around too. Thanks Khem. I also do not agree that we lack a self-sustaining community. OpenEmbedded has functioned independently for far longer than the Yocto Project has existed. Philip -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]
On Aug 7, 2015, at 5:26 AM, Alexander Kanavin alexander.kana...@linux.intel.com wrote: On 08/07/2015 12:17 PM, Philip Balister wrote: Thanks Khem. I also do not agree that we lack a self-sustaining community. OpenEmbedded has functioned independently for far longer than the Yocto Project has existed. By 'self-sustaining' I mean 'being able to continuously produce quality work'. Looking at layers in meta-openembedded, not all of them are of high quality. Meta-gnome in particular is badly out of date, because no one wants to maintain it properly. If oe-core starts taking a lot more volunteer contributions, what a bizarre statement. Let me remind you OE is a open source project still and maintained by volunteers. and the same thing happens (a volunteer contributes a large set of recipes, then disappears), what is supposed to happen then? someone else picks it up or it rots and get relegated. Alex signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]
On 08/07/2015 12:17 PM, Philip Balister wrote: Thanks Khem. I also do not agree that we lack a self-sustaining community. OpenEmbedded has functioned independently for far longer than the Yocto Project has existed. By 'self-sustaining' I mean 'being able to continuously produce quality work'. Looking at layers in meta-openembedded, not all of them are of high quality. Meta-gnome in particular is badly out of date, because no one wants to maintain it properly. If oe-core starts taking a lot more volunteer contributions, and the same thing happens (a volunteer contributes a large set of recipes, then disappears), what is supposed to happen then? Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]
On 07/31/2015 02:14 AM, Andre McCurdy wrote: The number of high quality recipes which can be maintained in oe-core depends on the number of developers actively using and contributing to oe-core. More active developers means more recipes can be maintained to a high quality. My issue here is quality control. Someone still has to review the work of those volunteer developers, and take action when they fail to take action. Yocto at the moment does not have such a self-sustaining community process - it all still goes through 'core' oe-core developers, and those developers can't have any more workload. Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]
On 07/11/2015 10:57 AM, Richard Purdie wrote: This does touch on something I have wondered about for a while, which is whether the time has come to move the GPLv2 pieces to their own layer and possibly their own maintainership. Obviously there are pros and cons to doing that. Thoughts? I'm all for that, which shouldn't be surprising :) The rationale is that we need to keep the scope and breadth of oe-core sane and manageable. The emphasis should be on having lesser amount of high quality, up-to-date recipes than vice versa. That means a continuous lookout for possible things to remove. Qt4 is one such thing, old GPLv2 software is another. Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]
On Thu, Jul 30, 2015 at 5:06 AM, Alexander Kanavin alexander.kana...@linux.intel.com wrote: On 07/11/2015 10:57 AM, Richard Purdie wrote: This does touch on something I have wondered about for a while, which is whether the time has come to move the GPLv2 pieces to their own layer and possibly their own maintainership. Obviously there are pros and cons to doing that. Thoughts? I'm all for that, which shouldn't be surprising :) The rationale is that we need to keep the scope and breadth of oe-core sane and manageable. The emphasis should be on having lesser amount of high quality, up-to-date recipes than vice versa. To play devil's advocate, a counter argument could be: The number of high quality recipes which can be maintained in oe-core depends on the number of developers actively using and contributing to oe-core. More active developers means more recipes can be maintained to a high quality. By restricting the scope of oe-core you reduce the number of developers who are able to use it directly. If the developers who can no longer use oe-core directly lose interest in tracking master between releases or start to go off and maintain their own personal forks, then you reduce the number of developers actively using and contributing to oe-core. Whether oe-core is at a stage in it's life cycle where it would benefit more from growing it's developer base or from knuckling down and focusing on a smaller set of core functionality is an interesting question... That means a continuous lookout for possible things to remove. Qt4 is one such thing, old GPLv2 software is another. Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]
On Sat, 2015-07-11 at 00:20 -0700, Andre McCurdy wrote: GPLv3 was released in June 2007 and most GNU packages transitioned to it fairly quickly, so by definition, the pre-GPLv3 version of any GNU package is now very old and unsupported. We do have a precedent for keeping pre-GPLv3 versions alive though (a good thing for those of us who need them!). What makes parted different from the other pre-GPLv3 packages which are already in oe-core? Looking at the parted changelog, there have certainly been a lot of bug fixes since 1.8.7 (the last GPLv2 version) but it's difficult to tell how many are for functionality which would be relevant to a typical embedded system. http://git.savannah.gnu.org/cgit/parted.git/tree/NEWS RHEL 5 seems to have been maintaining it's version of parted 1.8.1 up until Jan 2013. RHEL's 33 patches might be a good source of fixes for parted 1.8.7. http://vault.centos.org/5.11/os/SRPMS/parted-1.8.1-30.el5.src.rpm As someone has volunteered to maintain the pre-GPLv3 parted recipe (and I'll volunteer as a secondary maintainer, if that helps) hopefully there would not be a serious maintenance burden on anyone who doesn't have an interest in the older version. This does touch on something I have wondered about for a while, which is whether the time has come to move the GPLv2 pieces to their own layer and possibly their own maintainership. Obviously there are pros and cons to doing that. Thoughts? Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
