In-line. On 13/07/16 15:50, Ilario wrote: I don't see any reason why Chef images would be more stable than lime-build release images. The only fact is the testing process which might be involved. However until we solve all this "mess" and we decide to go in a single direction, I accept your suggestion. Maybe instead of "unstable" (which is not the case because the release 15.09 should be stable) I would do "builds.libre-mesh.org" or something like that. Or maybe leave "downloads.libre-mesh.org" but announce on the web page that for the moment the safe way is to use the poor set of images provided by Chef ;) Not at all. These Images are manually compiled by Guido in some local machine. So there is no way to reproduce the same building unless you know the exact parameters Gui is using. I hope in next Chef releases we would use the ImageBuilder generated by lime-build. So there will be an actual way to reproduce it.

2016-07-13 16:31 GMT+02:00 p4u <pau(a)dabax.net>et>: Well, you were there when this was decided... http://lists.libre-mesh.org/pipermail/users/2016-April/000101.html There should be just one place where you can download the official stable release (official implies unique). Clearly, whatever is the official stable release, downloads.libre-mesh.org has to point at it. The problem that chef doesn't include many devices can be solved in next stable release. Gui wrote that Chef is using that, if I got him correctly. http://lists.libre-mesh.org/pipermail/dev/2016-July/000721.html

Done. * http://downloads.libre-mesh.org is pointing to Chef * http://builds.libre-mesh.org is pointing to lime-build binaries I think the text of the web page (Get it!) leaves not doubt about the differences. Cheers. On 13/07/16 17:36, p4u wrote:

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 14/07/16 02:23, Gui Iribarren wrote: I don't see this overlapping as a problem. There might be people (or communities) who prefer to use Chef but also who prefer to use lime-build. This last now supports Profiles so it is very easy to a community administrator to create its own profile with the set of packets required (for instance lime-freifunk-berlin) and keep it compiled automatically for each new release. I think the current text is quite clear regarding this: "For more targets and LiMe versions you can use the automatic generated, not tested, images from Lime-Build <http://builds.libre-mesh.org/>." However feel free to change it. To be realistic, there are hundreds of existing targets and many new appearing every month. So if we only publish release for the tested devices we will end up accepting very few hardware. Let say some community is using hardware X which is not yet supported by Chef because it has never been tested before. This community is forced to use "develop" which has a huge probability of having some bleeding bug which will make it not work as expected. The community administrators will think "this LiMe stuff does not work" and they will probably go for another option. So IMO it makes a lot of sense to publish release binaries for ALL the available hardware we can handle, even if it has not been tested. This is actually the current mission of whatever.libre-mesh.org as explained in the web page. Cheers.