Dropping support of outdated/poorly supported boards and modules

As a result of the 2021.08 VMA we would like to see if anyone still would like to keep support for the following boards:

Please post any additional boards/cpus/modules that are not maintained and generally not used.

The motivation behind this is that we can reduce maintenance burden (especially when doing big reworks, less boards to check on the CI) and improve quality (if someone actually uses these boards or features, it will probably not work as desired) for at the cost of removing boards that cannot be purchased or sourced anyways.

We will be adding visible deprecation warnings when building any of these boards and allow appropriate time for people to raise any arguments against this.

  • Yes, drop boards/features
  • No, keep everything

0 voters

Related posts

I don’t think a vote is needed here - if there is someone who wants to maintain it, than we can keep it, if nobody is interested in those anymore, we can drop them.

Even if we find a majority voting ‘Yes’ that doesn’t solve the issue of maintenance and if someone is dedicated to keeping those boards, a majority that lost interest should not discourage them. :wink:

While at the topic, what about the gnrc_gomach / gnrc_lwmac modules? Does anyone use those / know if they work or was it just a research paper that was dumped into RIOT?

It only claims support for a single radio (when that part of the stack should be radio agnostic) and the original author is long gone. Is there anyone who’s still able to maintain or even use this code?

I just wanted to use the new poll thing :slight_smile:

1 Like

Mh… I don’t want to fight over this, but this platform in particular I often used in the past to test 16-bit capabilities of GNRC. Other MSP-430 boards are often too small for that. Since I was not present at the VMA: What is the reason for dropping that one? IIRC there were even plans to integrate it into Murdock longterm.

@jia200x originally was talking about it. I guess because it uses the cc2420 that has some hardware constraints limiting some efficiencies of the radio hal. I think also because you can’t really purchase it anymore (I could be wrong).

For the record I have that board currently integrated with the HiL tests. I did want to suggest switching boards/radios to someone more accessible, like a dev kit, but that means some work for boards that potentially would not be used.

5 posts were split to a new topic: Keeping MSP-430 alive

If a more modern MSP-430 board is ported to RIOT (see this discussion), I would be fine with removing the z1. I only ever saw one of those boards at FU and experience tells it is only a matter of time before that one goes the bad.

After so much work to get it in it’s a bit sad to see the MIPS support go, but I guess if no one is willing to maintain and progress it, it does not make sense to keep it :cry:.

@jia200x originally was talking about it. I guess because it uses the cc2420 that has some hardware constraints limiting some efficiencies of the radio hal. I think also because you can’t really purchase it anymore (I could be wrong).

Hi all,

Just to be clear, the hardware constraints were the low memory capacity, which makes it hard to run modern use cases. In fact, the z1 only runs GNRC in minimal configurations and as it is, it doesn’t run other stacks (OpenThread, OpenWSN, LWIP). Furthermore, this boards are not that easy to get (and expensive).

Since there’s an ongoing migration to Radio HAL based drivers with unfortunately not so much man power, I’m not sure if this radio should be in the priority list. Although a HAL port for the cc2420 could reduce memory requirements, the use cases are still limited and we probably won’t benefit of the full potential of the layers on top of the radio HAL. On the other side it would be a pity to block the Radio HAL migration because of a single radio.

If nobody is willing to maintain this board/radio, I would be in favor of deprecation.

Regarding the z1, AFAIK there’s one in @fjmolinas CI, one at haw. I got one here. that’s the most available (to maintainers) msp430 we got.

We can drop the radio without dropping the hardware though.

I would like to add some more BOARD’s:

  • fox: copy of iotlab-m3, not available
  • mulle

add** sorry for the typo

+1

I don’t have any first hand info around Mulle anymore, but the company website has disappeared. It would not be unreasonable to consider this board no longer available.

@Maintainers so far there are only three votes on this, It would be better to get some more input :slight_smile:

Is Dropping just that or would that thing move to an abandoned repo (from where it can recover if someone wants to invest the time into the board/feature/cpu …)?

Is that really needed? We have the LOSTANDFOUND.md file for that. Previous boards went there as well. Lookup the commit the board / cpu was deleted there and use

git checkout  "<commit>~1" $(git diff --name-only "<commit>~1" "<commit>")

(tested with the removal commit of the chronos board) if you want to work on / use that board again.

Not sure, but maybe this is a/the better solution LOSTANDFOUND

on one hand i do not like old work getting kinda lost (see 30-08-21: you are also kinda sad for old work going away)
<–>
on the other hand having a second “unsupported” repo may not reduce the maintenance burden enough (would only solve for the reduce murdocks time per commit)

Maybe decorating “LOSTANDFOUND.md” with that instant git something old command would be good.