Re: [lime-dev] RFC: new LiMe release - lime-dev

21 Apr 2019

I would say there are more than two significant regressions, such as current chef will be
broken and libremesh will be less standard and less close to openwrt.

In the other side, the only pro is that librerouter will be integrated into the official
libremesh building tool. Would it not make more sense to integrate librerouter into
Openwrt instead of doing the opposite? Once librerouter will be an official target,
everyone will be happy. Just put some efforts here... (is there a point I'm missing
so librerouter should not became an official target?)

El 20 d’abril de 2019 17:00:42 GMT+04:00, Gui Iribarren &lt;gui(a)altermundi.net&gt; ha
escrit:
...
 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 &lt;pau(a)dabax.net&gt; 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/dqn46n9qmb8ijf1hj3wix4ox…

-------------------------------------------------.  
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 &lt;mail(a)aparcar.org&gt;
  > 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(a)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(a)lists.libremesh.org
>>> https://lists.libremesh.org/mailman/listinfo/lime-dev
>> 
>> _______________________________________________
>> lime-dev mailing list
>> lime-dev(a)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.