I've decided to choose Testing LEDE Project as my final thesis.
I will concentrate mostly on the Luci GUI and test automation with Robot Framework and Selenium, but I'd like to contribute to the project and have some general information about the development lifecycle and the current test strategy of the project.
Please help me by answering some of my questions about LEDE Project::
How is testing part of the development lifecycle nowadays?
Do you use boardfarm as the main testing framework? How many routers/platforms are included now?
What kind of testing does LEDE Project need?
What are the key functions that have to work before a release?
How many people are testing LEDE now?
Should I call it LEDE or LEDE Project? What's the proper name?
Sounds like an interesting project. I'm replying just to show my support. Unfortunately I don't know anything about LEDE testing. I know there's a build page, but you probably already know that.
I will have to guess again that if there were enough compute resources to do testing that the best place to start would be with the most popular devices. I don't know where the popularity data lives. They must have web logs for downloads so those would be a good start to develop a list of most popular devices.
This link will get you to the statistics that LEDE captures.
Unfortunately it does not appear that there are statistics by device, at least not with the data presented. I looked into the tool back when the original post was written, but it was not clear that the tool supported this detail.
I think it would be good to know the most downloaded packages (features) and binaries (Devices).
Can you make a clear if/then logic about the options and allowed combinations?
I added and improved the support for 802.11r in LuCI GUI based on original work by another user, so if there is a clear logic to the new options, support for them could easily(?) be added to LuCI.
I am using 802.11r in my home network, so the topic interests me. Setting up 802.11r has been rather cumbersome task, so far...
if WPA PSK
then
ft_psk_generate_local = 1 (required)
mobility_domain (required)
ft_over_ds (optional)
reassociation_deadline (optional)
fi
(ft_psk_generate_local is set to 1 by default if not specified differently)
(nas_identifier is automatically set to nasid or to macaddress)
I think that we could optionally generate a mobility_domain based on the SSID.
So a user using PSK must only enable the 802.11r check button to get a working seamless roaming environment.
Then he optionally can change the mobility_domain, ft_over_ds, reassociation_deadline and nasid.