Deprecation policy for old BSPs?

[Trevor Gamblin (threexc)]

I've been looking at the list of MACHINE options in the layer for a while, and (especially after creating the table listing them) I think we ought to have a policy for removing older and/or under-supported platforms. Here's a short list of examples:

1. The StarFive VisionFive (V1) does not even appear to be listed on their product list anymore, and it was three pages in a Google query for "starfive visionfive" before I saw a link dedicated to it instead of the VisionFive 2.

2. From an availability perspective: the BeagleV, which had a very limited run and is unlikely to get any future support.

3. Others like the Star64 may also be considered for removal over time simply because of the legacy kernel versions they use, although those should probably lower-priority than boards that aren't available at all (and someone may still be working on updating them).

4. Finally, I think it's worth considering whether or not we should have a removal timeline for boards which we currently support with vendor kernels, but are also seeing active development upstream and in this layer with mainline repositories. The OrangePi RV2 and other K1 boards are a good example - I'm not suggesting that we have to drop vendor support immediately, but from a maintenance perspective it may not be worth keeping both versions.

The greatest motivation for this, in my opinion, is making sure that we can reliably automate testing for all of the boards while focusing primarily on the ones that the community will have access to.

Thoughts?

[Alistair Francis (alistair23)]

I think deprecating old boards sounds like a good idea

[Khem Raj (kraj)]

I like the idea as well. We need a way to park them and perhaps a file called DEPRECATED.md to list the information about the board and last release before it was removed and short reason why, would be good enough information if someone wants to dig the support.

[Trevor Gamblin (threexc)]

For parking, what about some sort of CI workflow, or a small script in the layer, which checks the changes and warns if specific files are being modified, with an expected removal date for them?

[Khem Raj (kraj)]

Good thought, but I think it can not be exhaustive, and it can give false impression of it checking for everything that needs to be tracked.

[Trevor Gamblin (threexc)]

That's true. I'll think on it some more. Maybe emitting a warning to the user when a build is triggered for a BSP that is slated to be removed (with the removal release name/date) is enough. The PR template could potentially make a similar note, it'd just require updating on our end whenever we do it.

[Michael Opdenacker (michaelopdenacker)]

Totally agree. This will help to keep the layer clean, and share "clean" code between well supported boards.

[Trevor Gamblin (threexc)]

Hi all, I have created an initial PR for deprecation warnings in the layer: #625

Right now I have only included MACHINE values of visionfive and beaglev, but I think we should also consider the non-mainline K1 BSPs, since mainline support seems pretty good.

What do you all think?

[Trevor Gamblin (threexc)]

I've added two more commits for a DEPRECATED.md and a modification to the pull request template. Right now, DEPRECATED.md only lists what releases will remove certain MACHINE values. I wonder if that is enough, or do we need a table with a reason for removal, kind of like the table in the README.md file?

[Trevor Gamblin (threexc)]

Thanks Khem Raj (@kraj) for merging my initial PR. As mentioned above, it warns about the following MACHINE values:

• visionfive
• beaglev

What do you all think about adding to the deprecation list for 6.1? Do we need to keep the vendor variants for the K1 boards? Are there other BSPs you think we should deprecate?

[Khem Raj (kraj)]

visionfive 1 I am fine, it should go. I am not so sure for beaglev even though boards are no longer produced, I keep getting patches to fix it.

[Trevor Gamblin (threexc)]

OK, I can remove the beaglev from the warning list in a PR if we really want to keep it. What about the vendor OrangePi BSPs? Michael Opdenacker (@michaelopdenacker) and Alper Ak (@alperak) ?

[Alper Ak (alperak)]

If the mainline kernel support covers all the features provided by the vendor and you think it will simplify maintenance of the layer and make it clean, that's fine with me.

[Michael Opdenacker (michaelopdenacker)]

I agree with Alper Ak (@alperak). However we are not quite there yet in terms of mainline kernel support. And for OrangePi R2S we don't even have a mainline based machine. I hope things will get clearer for 7.2.

[Trevor Gamblin (threexc)]

Alright. Let's plan to keep them in for now, but I will periodically try and have us review which BSPs might be deprecated in this discussion thread.