Ok, I just changed it, check the libre-mesh.org site and tell me if it works for you. Thanks! On 13/07/16 16:31, p4u wrote:

In-line. On 13/07/16 17:21, Ilario wrote: One of my suggestions was to change to "builds", but not "unstable" because I still don't see why Chef images should be more stable than lime-build release ones. In any case, the important thing here is what we put on the web page because people will just click the link whatever the name of it is. But OK, I'll change to "builds" and redirect "downloads" again to Chef. I don't think the current Chef implementation can handle more than one different architecture. I'm not sure of that. Maybe in this last release he did it, but it has not been like this the last years. In any case, if it is like this then there should not be any difference between the generic binaries in Chef and the binaries of builds.libre-mesh.org. So what's the point for all this discussion? Lime-Build was kind of broken until now but it works fine now and compiles all possible targets.

On 13/07/16 17:36, p4u wrote: It does currently handle atheros and ar71xx, but i haven't used/maintained atheros targets since 2013. All i wanted to say is that: yes, multi arch are supported I've been feeding the chef with an ImageBuilder created with lime-build since the day you commited that feature into lime-build :) lime-build is the only way to nightly build bleeding edge code, we all agree to use it for that it can also be used (by advanced users = linux cli users) to build stable-release binaries (generic in principle but also customized, by placing files in appropiate dirs) this second use case overlaps with chef use case (build stable-release customized binaries, or download generic stable-release binaries). But chef is usable by a lot more users (windows, androids, etc) So i don't see a point in publishing generic stable-release binaries made with lime-build, if that will also be necesarily generated as well by chef (using an IB made with lime-build) I think it's more consistent to say "we publish/manage releases inside chef, both generic and customizations" and "we also publish generic, bleeding edge binaries, made with lime-build branch develop, at whatever.libremesh.org" the list of supported hardware (available binaries) at whatever.libremesh.org will be normally larger (but with less testing) than what's available at chef.libremesh.org a new router model, that has been tested to run fine on develop (i.e. whatever.libremesh.org), will be made available on chef (i.e. stable releases) during the next release cycle. We could also "backport" models availability to previous releases for some reason, but i'd evaluate it case-by-case all this is simply inspired by the "normal" openwrt/LEDE release schema

On 07/13/2016 11:31 AM, p4u wrote: In our (AlterMundi's) imperfect release strategy, we have considered stable the releases that have been tested to work in real world networks. This is also the source of those "ugly hacks" which usually are needed to get any release actually working "24/7". The short list of supported hardware is inherited from the same historic decision. We were building images for hardware we actually tested to work. Chef was created for AlterMesh. It is to be expected, now that there is more people involved in development, more "targets", and the firmware itself has changed to LiMe, things need to be adapted, or thrown away if not needed any more :) From my perspective, I prefer to have something marked as stable when it is actually useful to deploy in a real-world network. In our experience this is never the case for a new release. I actually would love to have some sort of test-suite we can run on a network to at least evaluate the main known issues in new releases. Radios instability, batman becoming "deaf", poor MCS mode selection, etc. We should also be able to test rough performance difference between two releases in the same network using standard parameters like latency, packet loss, throughput, etc. Our strategy for a long time been to select the most tolerable set of upstream bugs we could work around. This should change; we should have more success fixing upstream bugs so we can use most recent software. Cheers! Nico