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 <gui(a)altermundi.net> 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 <pau(a)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/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
><mail(a)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(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.
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
