On Mon, Mar 18, 2019 at 03:21:27PM +0000, Richard Purdie wrote: > 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.
Well openssl is another example which caused me most pain in various stable branches, mostly because of version-script.patch taken from debian, where we were changing ABI even during minor version upgrades (we have a few prebuilt binaries included in our images, which get completely broken just by small stable branch upgrade and getting new prebuilt binaries from other companies might be complicated as well as expensive, e.g.: http://git.openembedded.org/openembedded-core/commit/?h=sumo&id=1b430eef7131876bc735c22d66358379b0516821 ) So they might have good record of security fixes getting into stable branches, but not very good for keeping the ABI stable (partially self-inflicted by us). > 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. > > 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. I'm glad this wasn't targeted to me, because 1) I wasn't really complaining about you nor Armin nor Khem (and I'm sorry if that sounded like that) 2) after doing that for many years with meta-oe/meta-qt5 and many other layers I know how painful/depressing/ungrateful this patch juggling is (one of the reasons why I've walked away from some of it). But the resource issues is part of my point If someone explicitly asks for backport, then it's more likely he or she will verify that the upgrade fixes the issue seen there, if it breaks something else as well, then too bad and it will need another fix as well, but at least we can show that there was good reason for that backport in first place. In boost example (I'm not complaining, it's just good example for what I'm trying to say), I understand why it looked like safe upgrade and generally good idea to backport, but then when people complain and there is no explanation nor review on ML to show why the extra risk was worth it (and than the blame unfortunately falls mostly on Armin and you, instead of the requester of the backport). I mean: doing the upgrades, just because they are available (like AUH enforces) is more work for everybody and might cause some extra pain to stable branch maintainers and users. Are there (m)any people complaining that stable branches doesn't get enough bugfix updates (not counting those requesting the actual backport, because they see the bug in their product)? Regards, -- Martin 'JaMa' Jansa jabber: [email protected]
signature.asc
Description: Digital signature
_______________________________________________ Openembedded-architecture mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
