On 07/13/2016 11:31 AM, p4u wrote:
In-line.
On 13/07/16 15:50, Ilario wrote:
2016-07-13 15:39 GMT+02:00 p4u <pau@dabax.net <mailto:pau@dabax.net>>:
Hi.
After working and testing lime-build, I think we can publish again the
link to http://downloads.libre-mesh.org. I've tested (also Ilario) the
resulting images and they work fine.
Yep, lime-build is working but still I support the fact that we can't
indicate two different sources for stable images: chef and downloads.
So I would keep downloads pointing to chef and I would open a new
subdomain for downloading the development version of Libre-Mesh built
with lime-build. For example unstable.libre-mesh.org
<http://unstable.libre-mesh.org> or something similar.
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)
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".
I understand this. However I think these ugly hacks and everything
required to make a release work should be available in the Git
repository of such release. So anyone (including lime-build) would
be able to reproduce a working release. Adding this hacks just in
Chef does not help at all.
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.
Agreed.