Re: [lime] Project meeting tomorrow

Eliminar este mensaje

Responder a este mensaje
Autor: cri
Fecha:  
A: libremesh
Asunto: Re: [lime] Project meeting tomorrow


On 8/6/26 10:39 AM, Ilario via LibreMesh wrote:
> Tomorrow, Friday the 7th of August 2026 at 13:00 UTC (15:00 CEST, 10:00
> ART) there will be a project meeting!
>
> The list with all scheduled meetings is here:
> https://libremesh.org/communication.html#online-meetings <https://
> libremesh.org/communication.html#online-meetings>
>
> As always, the meeting is open and the participation of the whole
> LibreMesh community is encouraged :)
>
> Here the link for joining: https://meet.exo.cat/LibreMesh <https://
> meet.exo.cat/LibreMesh>
>
> And here the link where you can start proposing topics to be discussed
> and-or start writing down your opinions: https://pad.exo.cat/code/#/2/
> code/edit/-i0SKeDo4jvTtOc3atbN3lI6/ <https://pad.exo.cat/code/#/2/code/
> edit/-i0SKeDo4jvTtOc3atbN3lI6/>
>
>

hi to everyone,
here the notes of the meeting of today,
I paste here also to have instant reading.

https://pad.exo.cat/code/#/2/code/edit/-i0SKeDo4jvTtOc3atbN3lI6/

hugs Cristina

_______________________________

## Friday 7th August 13UTC


### People

Javier, Constanza, Ilario, Franco, Cri, Batata

### Topics

- contributing.md: let's add something on AI
- Conflicts resolution protocol?
- Testbed with real devices
- Battlemesh https://battlemesh.org/BattleMeshV18
- Updates about repo server and DNS
- New release?
- libremesh domain magement



### contributing.md: let's add something on AI

https://github.com/libremesh/lime-packages/blob/master/CONTRIBUTING.md

ilario: we could specify that using AI for pull requests is allowed but
that its usage has to be disclosed. **The code review is going to be
different if we know that a pull request has been done by an AI.**

For example, we got this pull request where a meaningless test was
introduced. A human would never have wrote that, as it is clearly useless:
https://github.com/libremesh/lime-packages/pull/1265/changes/e6e664343ef154ad750c429136511acf63314083
Also the amount of effort that the review should put in for fixing the
issues found in the pull requests: if a human is on the other side, the
effort makes sense, as the human will learn from the feedback. While if
the code is AI-generated, the review can simply spot the issues and ask
the original contributor to use AI to fix them. In this case, the
original contributor from Altermundi did not fix the spotted issue,
neither using AI:
https://github.com/libremesh/lime-packages/pull/1226

One risk of accepting a lot of AI code, is that the code could get
unmaintainable for a human and this will be an issue when AIs will all
get for payment.

Another risk is have problem because contributing of AI is "using a
tool" and this mean that if we include in "normally workflow" means that
we need to collect money to use it if will became under payment.

We could create templates for the new issues and pull requests including
questions like "did you use AI for this?".

So understand what is with AI or our CI or Script is important.

Javier: add more regression tests is vital to keep the quality

Franco: we should add an agents.md file to stablish some common ground
on how to contribute using IA agents.

* Ilario will make a pull request with the addition to contributing.md

Cri: we can discuss about the agents.md in the mailing list or chat and,
if needed, talk again about this in the next meeting

### Conflicts resolution protocol?

ilario: I had a conflict with G10h4ck discussing some changes
https://github.com/libremesh/lime-packages/issues/1241#issuecomment-5059110653.
In this case we can ignore the fact, for me it is ok to leave this
unresolved, but we should prevent more conflicts to remain unaddressed
as this generates a toxic environment where people are not willing to
participate, and this is even more harmful for minorities and new
contributors. So we could write some simple conflict resolution protocol
for the project. Obviously, we cannot force people to solve the
conflicts, but if the involved parts want to resolve it, we should help
them with protocols and support from the rest of the community.

Cri: it is common also in other projects, to have such protocol. In big
and diverse group of people is likely to have conflicts. Currently we
don't have a clear decision making process. We should also address this.
Now it is practically by consensus, but not all people can express
themselves in the same way, so we should improve the consensus-decision
making process. We can use the currently employed consensus for easy
topics, and keep the more structured way (to be defined) for hotter topics.

Javier: it is important and useful. There should be rules and
consequences for breaking the rules.

Ilario: shall we open 2 pads (one per protocol, conflicts resolution and
decision making) and approve them in the next meeting (in 1 month)?

Cri: yes, and let's review them in 1 year time

Javier: perfect

Ilario: we could start from an existing protocol, Cri do you have one we
can start from?

Cri: yess will share a book about this:
https://www.lunanh.com/post/creating-conflict-infrastructure-a-group-workbook

Cri: I can make a first proposal of document. The concept is to calm
down people and make them speak with each other. Otherwise there is need
of mediators and mediation in groups and with external help, in steps
involving more help in each step. Finally if all the mediation groups
failed, there is to take a decision about how to separate the
conflicting people.

Javier: lets pay attention to digital communication channels. In some
situations we need to have a ready to apply action, not a mediation over
long time. For example banning someone. Agree in what to do in
situations with agressions in on-line chats, real time, ban people

Cri: we have one month to explain the content of the protocol, for then
discussing in the next meeting

### Testbed with real devices

Franco: moved the libremesh-tests repository to the libremesh
organization and proposed the changes to lime-packages. Also, added a
runner on the libremesh organization. You will receive notifications for
approving the run on the physical testbed. At each power cut, the
testbed has to be switched on by a human, even if remotely. The testbed
is ready and working, there is space for adding 2 more devices. For the
bachelor thesis presentation: we will share the streaming link :)
We still have to move the rack to the university.

Javier: they did a very high quality work

Ilario: if you had expenses that the university is not covering, you can
ask the LibreMesh project to conver the expenses, let us know!

Franco: it is common that the students have some expenses, here it is
considered normal. Some vendor gave us hardware for free after we
explained them the project.

Javier: some devices are the ones sent by Aparcar, also Altermundi sent
some LibreRouters

Javier: we should advertise the availability of the testbed

### Battlemesh https://battlemesh.org/BattleMeshV18

Dates: Monday 2026-09-07 to Sunday 2026-09-13

Ilario: Please, Franco, Constanza and Javier, can you make an online
presentation of the testbed for the BattleMesh? (hopefully, they will
have an internet connection at the venue...)
BattleMesh contacts:
https://matrix.to/#/#Battlemesh:matrix.org
https://ml.ninux.org/mailman/listinfo/battlemesh

ilario: MathJud is preparing a small project to propose to ISOC (from
what I understood) that involves also testing and documenting LibreMesh
on some devices.

### Updates about repo server and DNS



### New release?

ASAP!!!

Compiling OpenWrt 23 using the Buildroot is difficult with nowadays
Linux and recent compilers. OpenWrt is not going to update OpenWrt 23
for supporting modern compilers. The binary images of the stable release
are available and the images can be compiled also with the
firmware-selector https://firmware-selector.libremesh.org/

Blockers:
https://github.com/libremesh/lime-packages/issues/1192
the not-too-old routers have DSA-supported swiches, which get crazy when
two LibreMesh nodes are connected via cable. We should either find a way
to maintain the double usage of ethernet ports (for mesh, connecting
another LibreMesh node, and for clients connection, connecting a laptop)
or activate by default only the connection for cabled clients (laptops)
and document how to switch to mesh connection (for connecting via cable
other LibreMesh nodes).

### Next meeting

Saturday the 5th of September 2026 at 13:00 UTC (15:00 CEST, 10:00 ART).