I used to have similar ideas, but... there is already too few people doing the recipe upgrade work. I would not want to reduce that number even further by adding more barriers and requirements. It's always possible for a human reviewer to ask to send the patch upstream, if it's likely to cause upgrade headaches.
There have been situations where people do upstream patches later than they are added to oe-core; I've upstreamed parallel rpm work, and gobject introspection cross compile support that way. Those are significant features, and it's best to thoroughly test and refine them first before going upstream. As for updates, I am regularly able to remove 'Pending' patches during upgrades; this means they did make it to upstream one way or another, or upstream fixed the issue independently, or the code was refactored and the whole issue is moot. Otherwise, if I am seeing a 'Pending' patch during upgrades and it cannot be trivially rebased, tested or even understood, and dropping the patch does not create build failures and passes the AB tests, to me that is good enough to simply drop the patch. If people add complex, invasive patches and don't bother to upstream them, then there is a good chance they will be removed some time down the road. This kind of removal happens, but very infrequently. There have also been situations where recipes accumulated so much cruft over the years (not just a pile of patches) that upgrades that preserve existing recipe become nigh-impossible; in that case I re-write the whole mess from scratch (e.g. perl, python3, rpm, webkit). I don't think the pending patches are a particularly bad problem; also, their number has declined since last year. Alex On Sun, 15 Dec 2019 at 19:38, Adrian Bunk <[email protected]> wrote: > I am wondering whether patchtest should send warning emails on > Upstream-Status: Pending > > In practice patches are usually forwarded upstream either at submission > or never.[1] > > Not upstreamed OE-only patches create a technical debt that often makes > recipe upgrades a pain. > > cu > Adrian > > [1] When upstream requires copyright assignment upstreaming > later is sometimes not even legally possible. > -- > _______________________________________________ > Openembedded-core mailing list > [email protected] > http://lists.openembedded.org/mailman/listinfo/openembedded-core >
-- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
