Hello Dev Team,
Im writing to inquire in regards to a stable release road map? Ive been pushing users to upgrade to Nighty builds here with in BAM / SFWEM every month. It not EZ to ask every one every month. I know that the DEV team has been busy with upgraded to mitigate the storms and UI improvements. Im hopping for comment on the path for a stable release. I hope that it could be first quarter 2022? I would appreciate a stable release in order to stop asking users upgrade to nighty builds every month, to keep the network stable!
Long Live AREDN!
73 & Happy New Year!
Mathison KJ6DZB
Im writing to inquire in regards to a stable release road map? Ive been pushing users to upgrade to Nighty builds here with in BAM / SFWEM every month. It not EZ to ask every one every month. I know that the DEV team has been busy with upgraded to mitigate the storms and UI improvements. Im hopping for comment on the path for a stable release. I hope that it could be first quarter 2022? I would appreciate a stable release in order to stop asking users upgrade to nighty builds every month, to keep the network stable!
Long Live AREDN!
73 & Happy New Year!
Mathison KJ6DZB
Rather than wear their patience thin, I would simply stop asking them to upgrade. The nightly builds are not to be considered for production devices anyway. I know a lot of hams routinely test nightlies for us, but I wouldn't if you need the network to work. Over the next couple months the risk of using a nightly will increase substantially as large rewritten modules of refactored Python code are included.
As for a production release glide path, we were hoping to wait until we had 802.11ac devices supported and a new production release of OpenWRT included. So we are at the mercy of their schedule. We are considering arguments for an interim release.
Having said this, we are always grateful for testing support from those who are able to do so.
Happy New Year, Mathison to you and the growing Bay area network.
Andre, K6AH.
- Recent improvements made to mitigate the probability routing storms has significantly improved network stability. I would go as far as to say that the FW 3.21.4.0 & 3.20.3.1 is unstable in the light of the recent large scale test. Running 3.21.4.0 & 3.20.3.1 FW significantly increases a networks susceptibility to the out of sequence routing storms.
- Recent improvements made to the pearl UI improve device stability. Resources limited devices with low memory benefit significantly. The improvements made to the UI benefit primarily benefit slower HW. The higher preforming HW benefit from the improvements as well. The fix doesn't provide a way around the foreseeable End Of Live for 432 equipment. Its identified ARDEN FW gets chocked up on 432 equipment. It may only be a short term fix, it prolongs device compatibility, and improve the UI on all devices. An interim release should be made before additional fixes are introduced. The effect(s) of a large rewrite of the UI may introduce unforeseen problems. Prolong device compatibility with an interim release before "large rewritten modules of refactored Python code" is introduced into the nighty path. An interim release would freeze the UI code before its refactored. If no other improvements are planed or pull requests pending,
- I completely agree "nightly builds are not to be considered for production devices anyway" but because the significant stability improvements afforded by running a nighty (as of 1/2/21) not found in the 3.21.4.0. Network stability has been significantly improved here on BAM / SFWEM because of "storm" related code contributions only found in the NIGHTY FW. Resulting need is to run NIGHTY FW to maintain stability. Pushing users to upgrade ~200 devices to a Nighing build FW is unrealistic. An interim release is needed to bring the most recent advances made in AREDN out the wide spread network.
- Will further OpenWRT upgrades break support for 432 equipment?
Alone I think the "routing storm" code fix would call for a STABLE release. Combine the UI improvements and the soon to come rewrite of the UI code. The need is all the more pressing for a STABLE release.73 Mathison KJ6DZB
I would echo that personally here at home, as well as on our small but growing network in Chicago, these nodes have been on the nightlies for testing purposes and because we have some lower resource nodes deployed at non-critical sites. I would like to get the critical sites that are currently on the stable firmware up to include the changes discussed above, as well as get the rest of the nodes off of the nightlies while the refactoring effort is taking place.
Thank you all for your reasoned comments. We will take them under advisement and let you know.
Andre, K6AH
Thanks for your input to this process.
Andre, K6AH
Appreciate all the effort you all put into the hobby.