Hello all, right now it's extremely difficult to remove anything from oe-core. The reasons are that either we don't know how removal will affect possible users, or we do know that and we don't want to upset them by sudden breakage and 'flag days'. Especially if those users are supporting the project through membership fees.
On the other hand the maintainers burden is only growing as more and more things are being added into core. This has consequences, the most damaging being the resulting burnout, or coming dangerously close to it. It's not just RP pushing himself into unhealthy territory: all of us are, and me as well. Spending most (or all) of the time on routine, unappreciated things that hold no interest or fun is not healthy; there must be time and space for exciting, novel, fun activities. Yes, even when one gets paid for it. To steer things into a healthier, more sustainable direction, I'm proposing a two stage deprecation process for things that should be either maintained elsewhere, or dropped altogether: 1. Phase one: if a deprecated feature or recipe is enabled, users get a warning at the start of the build and an invitation to describe their usage of the feature in public (e.g. oe-core list or a bugzilla ticket). Otherwise nothing changes: the autobuilder testing of the deprecated item remains as it was (with a tweak to enable it explicitly rather than through poky/core defaults if needed), and the build is not going to fail. This would allow the project to more accurately assess the usage of the feature, and whether the users are willing to allocate resources towards keeping it alive. Right now we often simply have no idea about those things, just a vague feeling that it's not particularly useful or used. We have to force users to come out and tell us what they use and how. At that point, we could also hand them the list of open bugs, intermittent autobuilder fails, etc. caused by the thing they rely on, and see how that is taken. 2. Phase two: taking this feedback into account (also there might be none!), the feature is dropped from the autobuilder test matrix, and optionally relocated to its own layer. No maintainer is assigned to that layer until someone steps up. How long between phases one and two? At most, four yocto releases, so that there's at most one LTS release occurring in that period, complete with deprecation warnings that all LTS users will see. Ideally, it should be just one yocto release. What would I like to deprecate? I wrote that down, then realized it's a highly flammable, explosive list, and each of those items should be discussed separately, and only after we agree to the overall approach without bikeshedding about individual items. Thanks, Alex
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#63165): https://lists.yoctoproject.org/g/yocto/message/63165 Mute This Topic: https://lists.yoctoproject.org/mt/106239047/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
