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 Andreas > > There is huge pressure from people to get changes into stable quickly. > I cannot get people to test changes in master for a time period before > requesting backport. There is also huge pressure to accept no changes > that break anything or impact any workflows. My personal answer to this > has been to work on our testing, I've spent months trying to make > things more efficient, increase coverage and better able to highlight > problems. I don't see much other help/interest in it. > > I've also just spent a week away from home trying to explain to > companies why they might care about us having servers for a decent test > infrastructure (ideally to them we'd abstract it into the could and it > would all happen by magic, paid for by ether). > > I guess my ask here is that as well as complaining to Armin and myself > when we mess something up (sadly we are likely to do it again much as > we might try not to), please also highlight to the people who depend on > the project that we do need help with things like patch review and > other resources e.g. YP membership. > > Cheers, > > Richard > > > > _______________________________________________ > Openembedded-architecture mailing list > [email protected] > http://lists.openembedded.org/mailman/listinfo/openembedded-architecture _______________________________________________ Openembedded-architecture mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
