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 (#1796): https://lists.openembedded.org/g/openembedded-architecture/message/1796 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]] -=-=-=-=-=-=-=-=-=-=-=-
