Re: [lime] Meeting minutes 3rd of January

Delete this message

Reply to this message
Author: Javier Jorge
Date:  
To: LibreMesh.org project mailing list
Subject: Re: [lime] Meeting minutes 3rd of January
Dear Ilario and LibreMesh,

I apologize for not being able to attend the meeting. However, I would like
to contribute a proposal for the GSC 2025 program.

The proposal is at the end of the pad, it is about "wifi simulation and
qemu", it was mentioned a year ago but at that time I could not mentor it.
Now I can mentor the project. Please let me know if you need any additional
information or have any other suggestions.

Best regards,

Saludos,
Javi

On Fri, 3 Jan 2025 at 15:25, Ilario via LibreMesh <libremesh@???>
wrote:

> Hi all!
> Please find below the log of today's meeting.
> All the logs for 2025 will be here:
> https://pad.exo.cat/code/#/2/code/edit/ZE7xHnNUW8wlFscPc+ULRqT2/
>
> The next meeting will be on:
> Saturday the 1st of February 2025 at 13:00 UTC (14:00 CET, 10:00 ART).
> https://libremesh.org/communication.html#online_meetings
>
>
>
> ## Friday the 3rd of January 2025 at 13:00 UTC (14:00 CET, 10:00 ART).
>
> ### People
>
> Cri, Pony, Gio, Ilario, Gothos
>
> ### Topics
>
> * Archive meetings' minutes 2024
> * Release 2024.1
> * Testing grant: status of Hiure's one and funding a new one
> * Google Summer of Code 2025
> * Scheduling more meetings?
> * Updating the list of admins of the repositories on Github
> * Ethernet configuration
> * dev case use and personas: time steps
>
> ### Archive meetings' minutes 2024
>
> Cri did this for 2023, can do it again for 2024
> Cri will do it for 2024 also
>
> ### Release 2024.1
>
> A few small fixes have been cherry picked to 2024.1 branch, they should
> be safe to include in the release.
> https://github.com/libremesh/lime-packages/tree/2024.1
>
> Gothos can compile the release.
>
> Gothos is improving the build process using Docker, will send am email
> with the details of the process.
>
> Gio: currently LibreRouterOS uses most things from LibreMesh and is
> built with a script that takes OpenWrt and adds LibreMesh files. There
> should be no more stuff to pick to LibreMesh.
>
> Ilario: should we include by default also deferrable-reboot?
>
> Gio: it is difficult to make a 8 MB image, so I would avoid adding stuff
> that can be spared, but deferrable-reboot is small, so it should be ok.
> It can be disabled in the configuration (setting a long delay before
> reboot). The name is confusing. It should be something watchdog related.
>
> Pony: in OpenWrt there is WatchCat
> https://openwrt.org/docs/guide-user/advanced/watchcat
>
> Gio: if it does the same, we can drop deferrable-reboot and adopt
> watchcat. deferrable-reboot is coming from QuintanaLibre network, maybe
> they did not check if such a tool exists.
>
> Cri: we are going OT. Anyway it will not be included in mini image.
>
> Ilario: ok, let's not include it in this release, we have to try
> watchcat before.
>
> The version should be set with a commit like this:
>
> https://github.com/libremesh/lime-packages/commit/2e50c6c45fb166b3ba16fbd062dc8e4f66923cd5
>
> Name of the release "Fantastic Forwarder"
> https://lists.autistici.org/message/20231027.124816.b94a37d1.en.html
>
> Ilario makes the tag and sets the release name.
>
> ### Testing grant: status of Hiure's one and funding a new one
>
> Draft of the next grant:
> https://pad.exo.cat/pad/#/2/pad/edit/X27kEbYUhJiJ5twKIBVHHVlT/
>
> Cri&Ilario: In the previous meeting we observed that 400-500 $ was not
> enough for working on the grant and acquiring the required hardware. 800
> $ for the next grant.
>
> Cri: part of the money go to fix the issues found in the testing. People
> who receive the grant could be unable to fix the issues. We can have two
> separate grants: testing and fixing. Personally not interested to take
> the grant, nor anyone in the Valsamoggia community. Good occasion for
> writing properly the grant.
>
> Pony: Personally no time until the beginning of April.
>
> Ilario: No hurry, let's improve the grant text and send it around March
> and let's see who applies.
>
> Pony: Testing DSA is useful but we need to test also swconfig. Difficult
> to test the roaming, it mostly depends on the client when to switch AP.
> The grant currently says that the bought devices should be available for
> future testing, but this depends on the future availability of the
> person. In this case, these devices could be sent to someone else. The
> testing grant should be more clear on this.
>
> Cri: We can keep money for paying the shipment of the devices. Until
> when we buy another set of routers, so that we don't have to send the
> routers around.
>
> Ilario: let's remove the tests about the roaming.
>
> ### Google Summer of Code 2025
>
> Ilario: In 2024 I did not feel I was mentoring closely enough. Cannot be
> mentor for 2025.
>
> Cri: Can be mentor for 2025.
>
> Ilario: The project should be well defined.
>
> Cri: GSoC is our main income, we should participate for 2025 also.
>
> Unused projects from 2024:
> *
>
> https://projects.freifunk.net/#/projects?project=libremesh_internet_control&lang=en
> maybe we are not really interested in this as it is questionable from
> a network neutrality point of view.
>
> *
>
> https://projects.freifunk.net/#/projects?project=implement_traffic_prioritization_in_pirania_captive_portal_for_mesh_networks&lang=en
> this requires a lot of hard skills, maybe it is too difficult.
>
> Gio: Tests on the network, that can be done between two nodes, like ping
> watch. Testing the MTU of a path (fast ethernet cannot support more than
> 1500 B of MTU, while gigabit can support jumbo frames). Useful for
> setting a bigger MTU on the links that support it. Also, the nodes could
> suggest the user to change channel. The new shared state could be useful
> for that.
>
> Ilario: A project could be about a layer2-only image of LibreMesh for
> small and easy networks. Pedro proposed a project for supporting Babel
> via BIRD2 instead than Babeld.
>
> Gio: Good the BIRD2, as it could resurrect the BGP implementation also.
>
> Cri: Roaming for phone calls.
>
> Ilario: 802.11r for roaming? Auto-distance feature.
>
> Pony: There are two packages in OpenWrt improve roaming, a project could
> be to include them in LibreMesh.
>
> Let's draft the projects here:
> https://pad.exo.cat/code/#/2/code/edit/9IRFoOCL1mUnEXWDwdjgfR09/
>
> Internal deadline end of January 2025
>
> ### Scheduling more meetings?
>
> https://libremesh.org/communication.html#online_meetings
> For now not, in the future we can add more meetings.
>
> ### Updating the list of admins of the repositories on Github
>
> Current list of admins:
>
> * a-gave
> * altergui
> * amuuza
> * André Gaul andrenarchy
> * AngiieOG
> * Axel Neumann
> * Benny Lichtner
> * bruno vianna
> * Daniel Golle dangowrt
> * digitigrafo
> * FreifunkUFO
> * G10h4ck
> * Gabriele Gemmi gabri94
> * hiurequeiroz
> * Ilario Gelmetti
> * javierbrk
> * luandro
> * nicoechaniz
> * Nicolás Pace
> * Nicolas North nordurljosahvida
> * p4u
> * Pablo Castellano
> * Paul Spooren aparcar
> * raylas
> * Santiago Piccinini
> * selankon
>
>
> Keeping only:
>
> * a-gave
> * bruno vianna (?)
> * Daniel Golle dangowrt (?)
> * digitigrafo
> * G10h4ck
> * hiurequeiroz
> * Ilario Gelmetti
> * javierbrk
> * Paul Spooren aparcar
> * Santiago Piccinini
> * selankon
>
> Additionally, adding:
>
> * pony1k
>
> Pony agreed.
>
>
> ### Ethernet configuration
>
> This is the issue:
> https://github.com/libremesh/lime-packages/issues/1121
>
> Ilario: In the past meeting, Javier mentioned that he was working for
> exposing the LAN-or-mesh ethernet port configuration via the lime-app.
>
> Pony: DSA cannot have an interface both in standalone and bridge mode,
> that was ok for swconfig routers. Porposal: deactivate routing protocols
> on interfaces by default. With swconfig would not change anything.
>
> Pony: this pull request will also help distinguishing between DSA
> interfaces and old-style ones:
> https://github.com/libremesh/lime-packages/pull/1154
>
> Ilario: let's include that fix in a 2024.2 release.
>
> ### dev case use and personas: time steps
>
> Cri: Adding to the website the usecases, and link these usecases to
> humans. The website is a bit too technical, we should explain people
> what they can use LibreMesh for. For next meeting I can propose a text
> with the list of the usecases. To complete before the summer. Some have
> been listed in a previous meeting with Hiure.
>
> --
> LibreMesh mailing list
> LibreMesh@???
> https://www.autistici.org/mailman/listinfo/libremesh
>