On Mon, Mar 18, 2019 at 05:04:43PM +0100, Andreas Müller wrote: > On Mon, Mar 18, 2019 at 4:21 PM Richard Purdie > <[email protected]> wrote: > > > > On Mon, 2019-03-18 at 15:59 +0100, Martin Jansa wrote: > > > On Mon, Mar 18, 2019 at 12:49:17PM +0000, Richard Purdie wrote: > > > > Recently this issue came to light around some lttng* version > > > > upgrades. > > > > I do think that particular upstream is in keeping with what we'd > > > > need/want from a stable branch. > > > > > > There is also quite a bit of discussion related to recent boost > > > upgrade > > > in thud: > > > http://lists.openembedded.org/pipermail/openembedded-core/2019-March/280163.html > > > > I personally don't think boost should have gone in and that was a > > mistake. It comes down to too few trying to do too much :(. > > > > Not sure whether we should try and back that out or not at this > > point... > > > > > > Does anyone strongly object to this? > > > > > > No objection from me, but it would be good to keep > > > "Requesting a fix in a stable branch" section mentioned in: > > > http://lists.openembedded.org/pipermail/openembedded-core/2019-March/280177.html > > > in mind even more while doing this. > > > > > > There is always a risk of breaking the stable branch even with minor > > > upgrade, so we shouldn't take all minor upgrades from newer branches > > > just because they exist - until someone asks for backport because of > > > security concerns or bugs found while using such stable branch. > > > > I think in the recent climate there is a strong case for kernel stable > > series or openssl, requested or not (presumably someone would request > > regardless). The boost change was an exception rather than the rule and > > to me its a sign we need to get better at review. > > > > I'm going to say something here and its not directed to Martin but to > > everyone. > > > > I personally get *really* depressed when people complain about the > > processes when it breaks for their personal situation. Some people like > > Armin and like myself try and juggle hundreds of patches and keep > > everyone happy. There has been a huge change in project resources and > > yet we're keeping going fairly unchanged. The fact quality hasn't > > totally collapsed is frankly quite amazing in some ways. > I feel addressed here: > > 1. Yes I was upset because I am under pressure either, had a plan of > what to do next and that did not work due to boost update. The tone of > my email was not appropriate: Sorry - was not the first time - I have > to get better. > 2. My intention was not to point on people not doing a good job. I > wrote this to change something so that the chances this happens again > can be reduced. This discussion shows that my post was not for > nothing.. > > Regarding boost: There was an API change 1.68 -> 1.69.0 - but please > don't overestimate this: It's not clear why this came in and should > not have happened and we are looking for a solution to avoid in the > future. > > [1] https://www.boost.org/doc/libs/1_69_0/doc/html/signals2/api_changes.html
FWIW: you're not the only one seeing issues related to boost upgrades, e.g. meta-ros was affected by 1.67 as well as 1.69: https://github.com/bmwcarit/meta-ros/issues/592 https://github.com/bmwcarit/meta-ros/issues/618 it's a bit more complicated with meta-ros, because it tries to be compatible with as many Yocto releases as possible from single master branch (with README documenting some tweaks you need to do in your own layers to be able to use it like that). Again I'm not complaining about anybody and anything, just documenting the reasons why boost should probably be on that blacklist (or not be on the whitelist).
signature.asc
Description: Digital signature
_______________________________________________ Openembedded-architecture mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
