<div><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Oct 19, 2019 at 2:56 AM <<a href="mailto:richard.purdie@linuxfoundation.org">richard.purdie@linuxfoundation.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, 2019-10-18 at 20:49 +0200, Alexander Kanavin wrote:<br>
> I certainly don't mean to ignore those reports, it's just that due to<br>
> my ongoing health problems, and having to dedicate most of my energy<br>
> to the day job (<a href="https://mbition.io/en/home/" rel="noreferrer" target="_blank">https://mbition.io/en/home/</a>), I am not currently able<br>
> to work on the upstream issues in a timely manner the way I used to<br>
> when maintaining core was actually my day job (at Intel).<br>
> <br>
> The question of how much effort people who update things in core<br>
> should allocate to fixing 'other' layers has been a conflict point<br>
> for a long time. I'd prefer to see more aggressive<br>
> blacklisting/removal of recipes that no one has an interest in fixing<br>
> and updating.<br>
<br>
If anything this would be my fault for merging things despite there<br>
being concerns raised. I have to admit I'd seen other patches and<br>
therefore erroneously thought the issues we mostly resolved.<br>
<br>
Should OE-Core block on all issues being resolved before merging? I'm<br>
torn on that, I realise there are pros and cons.</blockquote><div dir="auto"><br></div><div dir="auto">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</div><div dir="auto"><br></div><div dir="auto">If there are too many reports then it would be questionable to block on it but I don’t think that’s the case </div><div dir="auto"><br></div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
It takes most of my time/energy to track the issues with core without<br>
trying to remember that patch X breaks layer Y and that I need a report<br>
back on that combination before I then find a patch and merge it.<br>
<br>
So sorry, I probably shouldn't have taken this :/. <br>
<br>
There is a fundamental issue with having enough people to help work on<br>
these things though and requiring more work for changes to be merged<br>
isn't going to help. I wish I knew what would help.<br>
<br>
Cheers,<br>
<br>
Richard<br>
<br>
<br>
<br>
<br>
</blockquote></div></div>