Remove unneeded variants (many esp variants with just a few different pinouts)
TBD
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.
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.
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?
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.
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 .
@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.
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.
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
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.
.