FWIW whilst this does fall outside normal policies, I think this is a reasonable course of action under the (fairly exceptional) circumstances. We would of course have to review future situations on a case-by-case basis.
Paul On Wednesday, 3 June 2020 21:27:00 NZST Richard Purdie wrote: > Hi All, > > We'd like to get the first 3.1 point release Dunfell LTS out soon. > There is one issue we need to resolve first. > > meta-arm has recently been established and the hope is to avoid > duplication of a set of recipes in multiple BSP layers, a goal which I > believe is in everyone's interests. As with any new layer there are a > few growing pains like the removal of python2 dependencies and its made > good progress but there is an issue we didn't foresee. > > Two of the key components that BSPs need from there (tf-a and optee) > which are needed for handling boot crypto have dependencies on > pyelftools and pycryptodome which were in meta-python in meta- > openembedded. In master we moved them to core: > > http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=d52929ee35d043211cb012e > 1b86409599a8b53c6 > http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=1e327abcc92d6575df5c18 > 71e6e1284987b74b87 > > and upgraded them to the latest versions: > > http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=cb94d9019b4d1ce32ad9196 > cb9c22236631e8781 > http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=7ebe299c00ec309cd46905 > ad40036d937fe609d7 > > For master that is easy, problem solved. > > For Dunfell, I've already seen complaints that using any of the BSPs > means adding meta-arm which means adding meta-python which pulls in > other chunks of meta-oe. Using a BSP shouldn't require pulling in large > numbers of other layers and this defeats what we're trying to achieve > with a granular layer model. > > Had we realised sooner, we likely would have taken this change into > dunfell before release but sadly we didn't. > > The LTS policy is quite clear we now shouldn't make a change like this. > Equally, we're early in Dunfell's development, we have an unforeseen > issue which is causing users real world pain. > > Our options are: > > a) Do nothing > b) Move the recipes > c) Move the recipes and take the upgrades > > Given the impact on end users and the desire to have good user > experience with our first LTS, as the layer maintainer and having > discussed this with others and on the tech call yesterday, I am > strongly leaning to b or c. I think this issue isn't one Steve as LTS > maintainer or I as OE-Core maintainer can make alone and I'm therefore > referring to the TSC. Which TSC is a good question. LTS is owned by YP, > the layers by OE. As such I've cc'd both sets of TSC members. I've put > it to the architecture list so everyone can see why we're considering > this and any discussion on it. > > Considering the potential regressions, if a user upgrades both layers > with these changes things are fine. If the user upgrades meta-python > but not OE-Core, they get a build error which is also fine and > straightforward to debug. If the user upgrades OE-Core but not meta- > python, there is the possibility they could see old versions being used > due to layer priority (assuming we upgrade the versions) but this isn't > known to cause real world issues. > > We have the option of the patch to increase the OE-Core version and > then bumping the version requirement in meta-python to further improve > the user experience. > > I'm conscious there has already been talk of "favouritism". I would > stress this issue has actually been raised by end users and that is the > driving factor here. > > The fact there are interested member companies of YP does actually help > in some ways too since it means there are people available to help > handle any issues should there be unexpected fallout from this change. > > If we do this, I would say as a TSC member that we'd do it without > setting any precedent, this is being discussed based on the situation > at hand, in the future other situations would have to be looked at on a > case by case basis. > > I did quickly sound out the YP TSC at a meeting yesterday and I believe > on balance they're in favour of b/c, two of the OE TSC members on the > tech call yesterday were also in favour in principle. Whilst that is a > majority, that does leave a couple of TSC members who haven't seen the > discussion and everyone probably benefits from this having been written > down. > > Does anyone object to doing this? If we do it, do we upgrade the > recipes or not? I'm probably leaning towards upgrading too as up to > date crypto components are probably better than not updated and some > kind of parity with master now will probably catch more potential > issues. > > Cheers, > > Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1088): https://lists.openembedded.org/g/openembedded-architecture/message/1088 Mute This Topic: https://lists.openembedded.org/mt/74646262/21656 Group Owner: openembedded-architecture+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
