Thanks for all your review and feedback. I have added a new document into OE wiki with this document. Feel free to provide feedback and we can update the document accordingly
https://www.openembedded.org/wiki/Deprecation_Policy On Wed, Oct 18, 2023 at 6:16 PM Tim Orling <[email protected]> wrote: > > Inspired by this initiative: > https://lore.kernel.org/openembedded-devel/[email protected]/T/#t > > I have spent entirely too many hours trying to get po4a to upgrade and run > the ptests. Someone else can pick up the mantle if they care. > > On Wed, Oct 18, 2023 at 4:14 PM Martin Jansa <[email protected]> wrote: >> >> On Wed, Oct 18, 2023 at 2:48 AM Khem Raj <[email protected]> wrote: >>> >>> Hi All >>> >>> >>> Here is a proposal for deprecation policy for recipes and related >>> metadata maintained in layers under meta-openembedded repository >>> Once this is reviewed and adopted, it can be adopted for other layers >>> too if given layer maintainers find it useful. These points have been >>> discussed over yocto TSC and this is initial version for review. >>> This would be added to OE wiki once we have discussed it over here. >>> >>> Why: >>> >>> - Reduce the security gap >>> - Increase quality of layer and recipes >>> - Reduce technical debt >>> - Improved developer productivity >>> >>> Challenges: >>> >>> Obsolete code adds to maintenance burden. >>> Old code consumes developers’ time which could be better focused elsewhere >>> Can’t tell who is using things >>> Sometimes recipes are one-off contributions which are unmaintained >>> there might be a perception that obsolete/removed recipes from OE-Core >>> can be added to meta-oe >>> >>> Users aren’t often paying attention to development branches, only >>> release branches >>> >>> Full meta-openembedded builds consume significant resources. Long builds >>> slow down development and narrows down testing matrix >>> >>> Obsolete recipes adds inertia towards new developments >>> >>> Older/obsolete recipes tend to become of poorer quality more so over >>> time as they are either not brought to use latest stuff or are simply >>> missing it. >>> >>> Keeping this in sight, here is a proposal to define some guidelines for >>> community to assess recipe deprecation >>> >>> Deprecation guideline criteria: >>> >>> - Recipe is not buildable >>> - Recipe has known security issues (particularly high impact ones) >>> - package's upstream is not actively responding to build or security >>> issues (e.g. a large patch backlog) >>> - Functionality from recipe has been obsoleted by other recipes and no >>> longer commonly used >>> - Recipe has no activity upstream (no activity for e.g. 5+ years is a >>> concern) >>> - Recipe with many architecture exclusions and isn’t portable but not >>> hardware specific recipe >>> - It is not a key dependency for large set of recipes/layers (check >>> layer index using depends:[recipename]) >>> - Niche specific recipe may better moved to a more focused topic layer >>> - Poor quality recipe or recipe build environment with no maintainer >>> willing to improve >>> - Recipe has problematic host dependencies (e.g. 32-bit runtime) and no >>> maintainer improving situation >>> >>> Process: >>> >>> - Maintainer can remove if the decision is clear to them and has >>> discretion over the process >>> >>> - For unclear situations, exclude from parsing initially with reason >>> documented >>> >>> - Notification is in the form of a patch adding the exclusion >>> - After a reasonable time if not fixed, recipe is removed >>> - Recipe removals scheduled after each release point >>> - If someone addresses the underlying issues the recipe can be added >>> back or have parsing re-enabled. >>> - If there is a conflict, issue can be raised to OE TSC for a decision >>> >>> >>> Feedback is welcome >> >> >> FWIW: I fully support this. It's sad that it's needed, but as long as >> developers and maintainers don't grow on trees we don't have better option. >> >> Pity that we don't have any data about which recipes are actively being used >> and many projects don't track what's happening in master, so they won't >> notice that something they use doesn't build in master for years until they >> finally upgrade to newer release. The only indication that something is >> actively used is that there are actually people stepping up to update or fix >> it (hopefully not just because they noticed some new failure in "bitbake >> world"). >> >> I did large meta-oe purge in 2017-02 with PNBLACKLIST: >> https://git.openembedded.org/meta-openembedded/commit/?id=b7f480cc4c533106442ecfe3266d73dd5a6973e8 >> https://git.openembedded.org/meta-openembedded/commit/?id=00ba7da845b96a15b42550d15a343f7bc36392f8 >> then added deadline date in 2017-04: >> https://git.openembedded.org/meta-openembedded/commit/?id=cdb428e7c49899675ee7b7a43f6cecdb5b4c2546 >> and finally deleted them on 2017-08-31: >> https://git.openembedded.org/meta-openembedded/commit/?id=ec9e5ed06256ad92c818474cdb490dc0d3a0d0a3 >> >> These were all really failing-to-build-for-long-time recipes (not just >> obsolete or insecure) and still there were couple people complaining later >> why something was removed, so having document like this officially approved >> will hopefully increase the visibility of the issue and cause less surprises >> when the recipes are removed. >> >> Regards, >> >> >> >>
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1807): https://lists.openembedded.org/g/openembedded-architecture/message/1807 Mute This Topic: https://lists.openembedded.org/mt/102030832/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
