Hi Alex, On Wed, 2024-05-22 at 09:53 +0200, Alexander Kanavin via lists.openembedded.org wrote: > 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.
Sadly I don't think this is going to work. One purely technical and resolvable issue is that we don't run autobuilder builds with warnings. Once you have one warning you stop looking for other warnings and they breed and quality degrades. Any proposal where the autobuilder runs with warnings will therefore not work. That issue is solvable. Another issue is timescale. A decent portion of our users don't run day to day builds with master. We can agree they probably should, but people don't do many things they really should. If we're lucky they switch every six months but some switch every two years on the LTS (or worse). There has so far been an understanding that we wouldn't "pull the rug out" from under things they use. Given what you want to achieve above, I suspect six months of warnings is too long, let alone two years of them. If you do run warnings with such a long time frame, it also devalues them as people will start to just ignore them. Currently most users do tend to fix warnings which isn't something I want to "undo". So yes, there may well be a long list of things you want to remove from core, however, we also have to think about the project's use and why people use it. It is often because we're able to support many weird use cases and interesting scenarios that people do adopt and use the project. I don't want to have a clinical core that is so opinionated about how it should be configured, people can't innovate or experiment and go and use other tools and systems. Even taking some things which should be "uncontroversial" like ppc or mips support, there is a core of project members who do want and need at least some level of support for those architectures. There is some level of willingness to help too, it just doesn't work on the timescales we often run into problems and need them fixed within (e.g. upgrading to a new gcc whilst users of fedora 40 run into build issues). There is a bit of a point of pride that our tools can and do support the old and new like this. Where we have removed things like uclibc in the past, we probably did lose some userbase to other projects as a result and we did dent our reputation for being able to support wide and varied use cases. With uclibc, I agree it could be done in a separate layer if there was demand but it didn't happen as nobody had the time/skills to make that transition. I guess my other worry is even if you do get feedback saying "yes, we use this", how do you evaluate that. Does it only count if you support the project in some way? Do you have to have 5 people respond? 50? I suspect with a number of the changes you're thinking of, you'd argue they shouldn't be using XXX anyway. If that is the case, the process probably isn't needed and we should be moving more directly to making a decision and making a change, which is the direction I've been trying with a number of other changes. My final comment would be able removal vs simplification. I'm keen to try and simplify where we can as I think it is a much bigger problem than needing to remove things. The unpack changes do make devtool much simpler and we have scope to simplify in other areas too. Layer priority is another topic we need to revisit and there are things with the tooling around the signatures I still don't think we've fully explored. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#199691): https://lists.openembedded.org/g/openembedded-core/message/199691 Mute This Topic: https://lists.openembedded.org/mt/106239266/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
