Hi!
On 1/26/21 12:16 PM, Ilario Gelmetti wrote:
On 12/16/20 9:16 AM, Eric Anderson wrote:
15 dec.
2020 kl. 16:54 skrev Ilario Gelmetti <iochesonome(a)gmail.com
<mailto:iochesonome@gmail.com>>:
A question on this mailing list:
it has never been used for taking decisions on the project and is silent
since months, can we stop listing it on the website?
Is there another place where development discussion should take place?
No answer from the devs, so I'll try to answer:
Well you are one of the devs!!
This mailing list is still the official channel for development
discussion but actual decision have not often (never?) been taken here.
Some of the decisions have been taken in Github issues, which in my
opinion is ok, as it's easy to "watch" the relevant repositories, get
the notifications and participate.
Regarding where the other decisions were are being discussed, over the
years there have been various private channels for development
discussions (on Telegram [1], on Mattermost [2]). Nowadays these
channels are silent (no idea if there are others).
For example, some recent decision on the project's priorities (as the
BMX6 => Babeld migration decided around February 2019 [3], or the huge
effort for replacing LuCI by lime-app started around April 2017) have
not been taken neither on this list, neither on lime-users list, nor on
Telegram, or Mattermost, nor on the IRC/Element chatroom (at least not
in any channel I am present).
I don't want to say that those were bad choices, on the contrary, the
result of lime-app is really really impressive and the latest 2020.1
release works smoothly with Babeld! :)
Said so, I have no idea where the development discussions are currently
happening.
There are no discussions around the priorities and development of LibreMesh
as a whole that I am involved that are not in the github issues.
The appearance of the LibreRouter project [4] from Altermundi [5] with
the related funding and grants, and the development of LibreRouterOS [6]
(a distribution of LibreMesh, which means that it selects some packages
directly from the LibreMesh repositories. You can get its binary
releases here [7] and follow its updates here [8]) partially took over
the LibreMesh project agenda [9]. So, maybe now the decisions are taken
on some LibreRouter-related or Altermundi-related channel
I contribute mainly to LibreMesh from the perspective of the LibreRouter project trying to
feed and improve LibreMesh in general and not only for this use case. All the features or
changes that would impact other use cases that I contribute are discussed in the libremesh
issues and pull request (if they are not it is by mistake and not on purpose). Sometimes
there is no feedback, sometimes there is.
From the LibreMesh website, the statement in favour of public
communications have been removed as "misinformation" [10].
I am not sure but I think that Gio's intention on that change was only to drop matrix
from the official communication channels.
This lack of transparency in the communications brings
us to what, in my
opinion, is the main problem of the project: the lack of transparency in
the governance model [11].
I agree, and there is one level deep, to be transparent on something you have to know or
decide on that, so to have some governance. We have collectively established the do-ocracy
github governance on the lime-packages repo (having at least two reviews). If this is not
documented we should do it. The web does not have a governance model decided that I am
aware of. And there is no LibreMesh project wide governance model.
AFAIK the historic model used in LibreMesh was to gather once a year and take decisions
there. Last couple of years there was no gathering. Some of the original developers do not
contribute anymore or are not involved.
For me the underlying issue is that we have chronological sparse involvement in the
project, and then most put theirs time in coding and not in other ways of involvement.
For me the way to move formward would be to coordinate to gather online and have an open
hackaton so we can discuss and build from there. What do you think?
We often saw "Do-ocracy" mechanisms and open discussions, with the
involvement of active members from the community (and moderated by a
list of Github users, some of whom are visible here [12]). But some
other times, looks like a closed collective is taking the decisions.
Both governance models (do-ocracy or self-appointing council) would be
ok (with one detail: if a closed collective decides something big like
the BMX6 => Babeld migration, this should be announced publicly).
The problem (for me) is the lack of transparency which can frustrate
even the most motivated of the new contributors.
This situation can be thought, exaggerating a lot, as an early stage of
the LEDE/OpenWrt controversy [13].
I am not sure but I think that what you mean like "the babel migration" was not
intended to be like "now the default is babel". There have been many many
endless discussions on what are the default packages.
I think that we have to take a decision, if libremesh is a framework to support building
firmware distributions then there should be no defaults, and so no firmware binaries. We
may suggest "if you pick this list of packages then the result would be somewhat
functional", or have multiple lists.
Or we may decide that you can build other firmwares using libremesh but libremesh is a
firmware distribution that has a set of objetives and then select the packages and build
the firmwares.
But I think that we can't have both things in a sane way.
I tried to open this discussion on
https://github.com/libremesh/lime-packages/issues/749
Being LibreMesh a modular and open firmware, a strong community could in
principle support an alternative set of choices, but this is not easy
Yes, there is
a lot of work to even have one set of working packages. I know that some communities are
using
other set of packages than what is stated now in the documentation as the defaults.
There is the
IRC chat, but that requires attentively waiting for
replies, so I don’t think it’s suitable for the same kind of discussion.
The IRC channel is bridged to Element (previously known as Riot), which
is more convenient as it caches the messages. See instructions and
addresses on the communication page [14] on the website.
I participate in the chat from the matrix/element bridge.
Abrazos!
SAn