On Fri, 2019-10-18 at 20:49 +0200, Alexander Kanavin wrote:
> I certainly don't mean to ignore those reports, it's just that due to
> my ongoing health problems, and having to dedicate most of my energy
> to the day job (https://mbition.io/en/home/), I am not currently able
> to work on the upstream issues in a timely manner the way I used to
> when maintaining core was actually my day job (at Intel).
>
> The question of how much effort people who update things in core
> should allocate to fixing 'other' layers has been a conflict point
> for a long time. I'd prefer to see more aggressive
> blacklisting/removal of recipes that no one has an interest in fixing
> and updating.
If anything this would be my fault for merging things despite there
being concerns raised. I have to admit I'd seen other patches and
therefore erroneously thought the issues we mostly resolved.
Should OE-Core block on all issues being resolved before merging? I'm
torn on that, I realise there are pros and cons.
If an issue is there and gets reported after it’s merged I think it’s fine to do whatever is needed after the fact however if testing master-next from oe-core and reported against it I think this will help you in longer run if these master-next issues are looked into and blocked on. We should not run Oe-core so fast that other layers fall way back behind where they start supporting just releases and you have lost free integration testing that other layers would offer
If there are too many reports then it would be questionable to block on it but I don’t think that’s the case
It takes most of my time/energy to track the issues with core without
trying to remember that patch X breaks layer Y and that I need a report
back on that combination before I then find a patch and merge it.
So sorry, I probably shouldn't have taken this :/.
There is a fundamental issue with having enough people to help work on
these things though and requiring more work for changes to be merged
isn't going to help. I wish I knew what would help.
Cheers,
Richard