regarding releasing libremesh as a set of packages  , i absolutely agree, so much that  i did come up with exactly this idea a few weeks ago and even started to draft something here
https://github.com/altergui/packages/commits/merge-libremesh-in-openwrt
that just compiles lime-system, but idea was to extend it to compile all the lime-* packages and make a PR, ideally before openwrt-19.03 is branched
i hardly sat down with a laptop since then :(
would love to coordinate efforts somehow

regarding buildroot vs lime-sdk, the only way to work on hardware support for librerouter was to work on buildroot, so there was no decision to take at that point.
the decision was to work with buildroot AND THEN 3 more other complex and diverse tools (lime-sdk which in turn uses sdk and imagebuilder) or just focus on one single tool (buildroot). given limited humanpower, the sensible decision was to use a single tool

there are two significant regressions, tho: 
1) there's currently no organized repo of firmware customizations (think of altermesh profiles, or more recently github repo "network-profiles")

2) firmwares generated with buildroot cannot use kmod-* packages published by upstream

(just for context:
before 17.06 we "solved" this issue by compiling all kmod-* for ar71xx, publishing them under downloads.libremesh.org (or the like), and pointing opkg.conf to that repo. 
in 17.06 we used openwrt SDK to compile lime-* and then we could use official upstream kmod-*)
in my understanding this will cease to be a problem as soon as lime-* packages are simply part of upstream (when PR ir prepared and accepted), since the instructions to "cook" a libremesh firmware could be to simply download official openwrt 19.03 ImageBuilder and generate a binary with lime-blah packages, which will come bundled in imagebuilder along all other packages

On 16 April 2019 15:21:14 GMT-03:00, Pau <pau@dabax.net> wrote:
In-line.

On 16/4/19 0:40, Marcos Gutierrez wrote:
Hi, previously to this thread I wrote something similar in
Mattermost. I
 think that the fact that it is duplicating the conversation further
 reinforces what I raise.
 I copy and paste what I wrote before.

https://mattermost.altermundi.net/chaosmonekeys/pl/dqn46n9qmb8ijf1hj3wix4oxjy
-------------------------------------------------. 

I think the mailing list is the official channel we have been using for
a long time. So IMO this is the correct place for this discussions.

*Hello, team*. I think it's necessary to start some conversations. In
the last year I think we lost our way as team and pursued individual
or
particular agendas. In my case, I don't know what those agendas are.
But
this resulted in a decrease in the quality of the code, in completely
unattended communities and in the non-compliance with the releases.

      LibreRouter and LibreMesh

In my experience LibreRouter maintained some pressure on development
or
at least pushed it in some direction. I have noticed that some of the
user community misunderstands this by believing that what was
developed
for LibreRouter does not contribute to LibreMesh, when in fact they
go
along side by side. One of the changes, in terms of what was being
proposed from LibreMesh, is related to the development environment,
to
change for a more stable and functional one, replacing lime-sdk with
buildroot. My experience in both systems is that buildroot is more
predictable and transparent with errors, if any. I didn't notice any
extra complexity. It is currently under discussion how to apply some
kind of "recipe" that allows a follow up on the build configurations,
that did solve well lime-sdk.

That would be a **horrible decision** IMO. Our past tool (name
lime-build) used buildroot and we agree, after a looooong discusion, to
change to lime-sdk and use ImageBuilder+SDK. Please, find the documents
in the mailing list archive which are talking about this topic before
taking any kind of decision or opening this discussion again.

      Protocols

Bmx6 stopped its development and is still the default layer 3
protocol
in LibreMesh. The discussion about changing it (by bmx7, babel or
other)
never arose. I think this is part of what blocks a new release, since
there is neither a consensus nor accumulated experiences of use by
the
developed, at least not between all.

I really think jumping to bmx7 would be a good decision. I've been
using
bmx7 for a long time now and it works just fine.

      Release vs Develop

When I participated in the summit of community networks in Brazil I
was
surprised to see that they were installing 17.06 on the routers.
Since
that release was published we had almost 450 commits, many of them
minor
but others very important. Several of those issues were detected by
the
use of LibreMesh in our communities, the result of many headaches. If
we
don't publish an update we are helping to continue spreading already
solved bugs instead of being able to detect new ones. Another problem
I
noticed is the need to have OpenWrt 18.06.1. I didn't notice this
problem because I never used the release, I always used develop or
some
branch of my own, away from the experience of our users. Did the same
thing happen to you?

      Public roadmap

My proposal is that as soon as possible we advance in knowing the
private and public roadmaps, collective and individual of those who
develop LibreMesh. Then try to reach a consensus on what, when, who
and
how we are going to continue working and make that public.

*We build a software that works (however it is but works), that has
users and community but that lacks a clear direction.*

/If something is not understood it can be a translation problem, let
me
know and I will correct it. /

On 15/4/19 14:56, p4u wrote:
 I think thay could work and having a new release is quite a need.

 What we need, IMO, is someone moivated managing the technical part
 (that could be you), and some real scenario/realcase to test the
 release and brint feedback.

 El 15 d’abril de 2019 15:54:02 CEST, Paul Spooren <mail@aparcar.org>
 ha escrit:

     Hi all,

     it's been a very long time since we had a LiMe release, and
currently
     the state of master isn't the best, right?

     What do you think of the following:

     We determine a LibreMesh setup fitting most purposes, say Anygw,
Batadv,
BMX7, lime-app. Now we make sure this setup works, sure we have
more
modules and packages, but we focus for a time on these few
packages and
     make them work.

     Now, we kindly ask to get these packages in the official
repository of
OpenWrt, just like Freifunk did in the past. Now it's suddenly
super
easy to build LibreMesh, as it's fully compatible to the
official SDK.

     Once the setup works we can make a new release, saying that the
     combination of packages above (or a similar one) is officially
     supported, the rest is considered "unstable" as long as not in
the
     official repo.

     Would be happy to work on this for the next weeks until we have
     something stable. What do you think?

     Sunshine,
     Paul

     lime-dev mailing list
     lime-dev@lists.libremesh.org
     https://lists.libremesh.org/mailman/listinfo/lime-dev

 -- 
 Enviat des del meu dispositiu Android amb el K-9 Mail. Disculpeu la
 brevetat.
 lime-dev mailing list
 lime-dev@lists.libremesh.org
 https://lists.libremesh.org/mailman/listinfo/lime-dev
lime-dev mailing list
lime-dev@lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-dev