On 10/26/23 3:36 PM, Armin Kuster wrote:
On 10/24/23 2:18 PM, Khem Raj wrote:
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
It is unclear to me what the roll of "SKIP_RECIPE" is now and how may
be applied in the below policy.
Khem can speak for the current policy, but historically....
SKIP_RECIPE is used to declare a recipe doesn't work for some reason, alerting
people that they need to step up and fix it. If nobody steps up and fixes it
within a reasonable amount of time then it should be removed.
Some reason might be doesn't compile with the current gcc, kernel-headers, or
another library changed an API.. that kind of thing is pretty typical.
--Mark
- armin
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 (#1812):
https://lists.openembedded.org/g/openembedded-architecture/message/1812
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]]
-=-=-=-=-=-=-=-=-=-=-=-
