friendica LTS version
Hi there,
I wonder if it would be possible to consider, create and maintain some kind of friendica LTS versions. What I mean by that is defining some mayor stepping stones in the friendica development, define them as LTS version and only create an update with respect to crucial and important safety vulnerabilities.
I ask for that because as of now in general terms everybody is simply asked and obliged to update the existing friendica version to at least latest stable release to even get an answer about critical security issues when at the same time upgrading friendica is not necessarily an easy task. Personally I lost several friendica setups because I ran into trouble after updating them and because of not being able to solve them I had to abandon the setup all together and start from scratch or even abandon the intent to host my own friendica instance all together.
Out of those experiences, if I have a friendica server up and running, unless there is a real security issue, I can 't see any reason to update that instance.
In other post's to this forum I actually asked about specific friendica versions that marked such stepping stones. Versions like 2021.04 that was the last that had front end worker for shared hosting, an intention (shared hosting support) that had to be abandoned because in general terms it was to difficult to make it work, or 2023.05 as the last version before channels as something new were added, or maybe the version previously to where activitypub instead of DFRN took over the communication between friendica servers (if I got that right).
I didn't even got an answer about those probable stepping stones inside the friendica evolution.
🙁
Anyway, having in mind that for any kind of reason people might not want or need to update their instance to the latest version, in cases of important vulnerabilities as happened in 2020.07 or recently in 2023.12 (?) I think it's important to check out if such vulnerabilities date back and until what versions and how and if they can be fixed in those versions without having to update to the recent stable release. And wondering about these things the LTS option came to mind. That could be a way so people can at least consider to install a friendica version that as it is will work fine and in any case will get help if security fixes are needed.
Hypolite Petovan
•@utopiArte Thank you for the suggestion, however creating and maintaining LTS versions requires work hours that we simply can't afford right now. There is exactly one consistent developer on the project, it's @Michael Vogel , and I don't think there's enough chocolate in the world to make him do what you want.
The entirety of the Friendica project is structured around the time he spends working on it, and that includes time-based releases rather than feature-based, and rolling forward versions rather than branching versions (that could include LTS). Friendica is made to update incrementally, I'm sorry you had troubles updating your nodes but I believe Michael's simply stretched too thin to entertain your idea.
Friendica Support reshared this.
Michael Vogel
•In addition to what @Hypolite Petovan has already said, I would like to point out that I think that "upgrading friendica is not necessarily an easy task" is not really true. You can even set up a machine that updates itself automatically. All you need is to have installed your system using
git clone. And then all you have to do to update isgit pull origin stable && php bin/composer.phar install --no-dev(the same command without the composer has to be done inside the addon folder). And you could even put this in yourcronsetup so that it is done every day or every week.Also: Even if we had the manpower to maintain such an "LTS" version, there would still be a need to update the system frequently.
Concerning the "stepping stones". I read your message about this. But I can't answer this out of my head. I would have to read all the release notes as well, to be able to collect this data.
Roland Häder
•@Michael Vogel My #like to your comment isn't reaching there but it reaches on the copy on @utopiArte 's side: https://pirati.ca/display/ec054ce7-1465-fbbb-113c-4de553146487 versus https://tupambae.org/display/0ac89072-1365-fb94-cd46-192466864630
@Michael Vogel My #like to your comment isn't reaching there but it reaches on the copy on @utopiArte 's side: https://pirati.ca/display/ec054ce7-1465-fbbb-113c-4de553146487 versus https://tupambae.org/display/0ac89072-1365-fb94-cd46-192466864630
Michael Vogel
2024-03-21 04:44:01
utopiArte
•> There is exactly one consistent developer on the project
This is a problem by itself and I wonder if there is some possibility to address this maybe by trying to improve planning, outlining the "what to do" and "future goals" and somehow improving delegation of tasks?
On the security updates.
... show moreAs for what I can see/understand from here we had only two mayor incidents in the past (2020.07 and 2023.12). In the first place I guess there is some kind of incubation time where the fix is published and the update by the majority of instances is done. Once that quarantine time is over I can't see any reason to address the issue more into deep and educate the community on what is/was the problem itself, which versions and use cases are are affected and if there are perhaps fixes without updating everything by just pull/update certain modified files. I actually tried to reach out the last time (2023.12) asking for information more into deep about the problem to see if I could fix the problem on a 2023.05 version, even linking to the fixed files on github I could find conc
> There is exactly one consistent developer on the project
This is a problem by itself and I wonder if there is some possibility to address this maybe by trying to improve planning, outlining the "what to do" and "future goals" and somehow improving delegation of tasks?
On the security updates.
As for what I can see/understand from here we had only two mayor incidents in the past (2020.07 and 2023.12). In the first place I guess there is some kind of incubation time where the fix is published and the update by the majority of instances is done. Once that quarantine time is over I can't see any reason to address the issue more into deep and educate the community on what is/was the problem itself, which versions and use cases are are affected and if there are perhaps fixes without updating everything by just pull/update certain modified files. I actually tried to reach out the last time (2023.12) asking for information more into deep about the problem to see if I could fix the problem on a 2023.05 version, even linking to the fixed files on github I could find concerning apparently the issue.
I didn't get an answer at all.
And not getting an answer at all is the worst thing that can happen in communication. A "no chance to fix this in 2023.05" or "this security issue only can happen within your node, only a profile of your node can compromise another profile of your node" would have helped me out or at least clarified my doubts.
Instead I just stud there in the middle of the fog of not knowing.
What I mend by LTS was simply to say that I guess that there should be some friendica versions that where quite sound and complete as they were and that it should be possible, sooner or later, at least from now on, to look and say:
"Ok this is like a completed and polished evolutionary step in friendica" and mark it as such before moving on with some mayor changes in the DB or whatever, and when a real security issue comes up, to take a minute, look back and say "this most likely affects versions till XYZ", "this is maybe solvable by modifying the files X and Y of the pull request Z" and perhaps make some notes about where or why this might create trouble if someone tries to fix this in earlier versions.
_____
Thx @Michael Vogel for the hint about automated updates but the last thing I will do is to put some automatic update routine into my setup. I sat once in front of a blank page after an update and and when I started to read the help instructions, pointing me to my mysql DB and asking for queries and what not, the abyss of helplessness opened in front of me and my intention to just be able to live some basic freedoms of privacy and ownership of my own data in a common social web simply went down the drain with tons of posts, interactions and social contacts created with dedication from the loneliness of my reality. I don't want to become a coder nor a web developer I just want a work station that works as is, create content and have some communication.
I prefer to run this version as it is into the ground till the day it get's compromised, hacked or destroyed by time and space living meanwhile, instead of not knowing if the server shows up or not every time I open my browser, perhaps having to struggle with some code for days just to make it work again or maybe not ..
Hypolite Petovan
•@utopiArte @Michael Vogel
I don't think so. Not only someone™️ would have to do some work to make the planning, but there's no guarantee any of us would follow it as we've been exclusively working on what we wanted so far.
That's why the poll feature is partial, lacking a way for Friendica users to vote. That's why the reporting feature is incomplete, still missing comprehensive administration pages. If we didn't have enough motivation in ourselves to finish these features, nobody else will compel us to do it.
Friendica Support reshared this.
utopiArte
•In the first place I guess my worries go to the documentation part of the code itself. In other words, what happens the day the main developer isn't available anymore, has the coding documentation gone on like Mike initialized it describing into detail what the code does?
Besides that my main point is "just" about organization and communiction with respect to the tasks.
... show moreI have no idea how this is normally done or how it is done on and for friendica. As of now what I do consider is that the fediVerse itself is growing, also in attention, and there for we should look out and prepare for people and coders who want to help and add labour that they can do so.
I tried to throw some ideas and requests on the table for the forum pages to do so but basically there was a lack of response. From that perspective I wonder if we should think, work and wonder on communication and organization skills. Not every one is good at comunicate, integrate or "public relations" while being good at coding or "talking to computers".
Also, there is AI coding around the corner, so maybe in a ve
In the first place I guess my worries go to the documentation part of the code itself. In other words, what happens the day the main developer isn't available anymore, has the coding documentation gone on like Mike initialized it describing into detail what the code does?
Besides that my main point is "just" about organization and communiction with respect to the tasks.
I have no idea how this is normally done or how it is done on and for friendica. As of now what I do consider is that the fediVerse itself is growing, also in attention, and there for we should look out and prepare for people and coders who want to help and add labour that they can do so.
I tried to throw some ideas and requests on the table for the forum pages to do so but basically there was a lack of response. From that perspective I wonder if we should think, work and wonder on communication and organization skills. Not every one is good at comunicate, integrate or "public relations" while being good at coding or "talking to computers".
Also, there is AI coding around the corner, so maybe in a very near future it might become much less time consuming to create or improve something and there for it's reasonable to prepare/discuss the upcoming tasks/requests with more dedication so when there comes a time things fall into their slots it will work out as good as possible.
Actually I was amazed by one of @deadsuperhero@libranet.de 's takes on the last fediverse "summit" about how much monthly support lemmy is cashing in by patreon (or things like that). That might be also something the community could have an eye on.