Zum Inhalt der Seite gehen

Hello !Friendica Developers,

I'm testing my Friendica test instance on my server. I noticed some flaws and bugs and reported them on Github. While looking at the code I think there is some minor and major refactoring needed. Where is a good place to meet some maintainers like @Hypolite Petovan to talk about the roadmap? Is this group the best place?

@Hypolite Petovan !Friendica Developers

Friendica Developers hat dies geteilt.

Als Antwort auf art4

Tobias
Tobias
• •

Hey @art4 , yes this group is the place. If you want to meet devs in person, my guess is that 38c3 would be perfect as most of the core dev team will be there.

Issues on github also help to improve the software :)

@art4
Als Antwort auf art4

Hypolite Petovan
Hypolite Petovan
• •

@art4 i Art and thank you for using Friendica! I'm not as involved anymore which means that the Friendica roadmap is now whatever @Michael Vogel , blessed his name, feels like working on.

This also means that if you see something that should be done with the code, provided it doesn't change tens pf file, you should do it yourself and submit a PR on GitHub.

@art4 @Michael Vogel
Als Antwort auf Hypolite Petovan

art4
art4
•

Thank you.

This also means that if you see something that should be done with the code, provided it doesn't change tens pf file, you should do it yourself and submit a PR on GitHub.

May I ask what do you mean with "it doesn't change tens pf file"? (I assume "tons of file"). What would be the problem with that? It is very likly that this will happen during a refactoring. As long as BC is provided it shouldn't be a problem.

Friendica Developers hat dies geteilt.

Als Antwort auf art4

Michael Vogel
Michael Vogel
• •
@art4 @Hypolite Petovan @Friendica Developers If you have questions, just ask them here. On GitHub we have got an exhaustive list of feature requests. The question is, what do you prefer to do.
@art4 @Hypolite Petovan @Friendica Developers
Als Antwort auf Michael Vogel

art4
art4
•

Thank you. To be honest: The exhaustive list of issues on Github is the reason why I'm asking this questions. 😅 I couldn't get through all 1,2k issues so far to get the big picture.

I would like to know if there is any place like a roadmap or plans for the next releases? The roadmap on Github seems to be outdated?

How are the issues on Github managed or prioritized? Are there special tags what should be done first? i.e. I saw this issue github.com/friendica/friendica… with a fix deadline for August 1st 2025 and opened a PR for it. Is there a place or list with more issues like this?

About me: I want to switch my #fediverse server from #Mastodon to #Friendica. I'm doing refactoring of web applications (especially in PHP) for nearly 15 years. In the last years I helped refactoring SimplePie and a PHP client for the Redmine API (full disclosure: I'm now a maintainer in this projects) to name two publicly available projects.

I would like to help Friendica too. At the moment I'm analyzing the project to create a potential plan (if there isn't one right now) for the refactoring. Next I would like to stabilize the code base and improve the test suite and the testability of the code.

#mastodon #fediverse #friendica

Friendica Developers hat dies geteilt.

Als Antwort auf art4

AndiS 🌞🍷🇪🇺
AndiS 🌞🍷🇪🇺
• •

As a interested bystander and Friendica admin/user I'd say this would be truly helpful to the project. There are only very few pople actively working on friendica and they have all my respect! But as its an old project with a grown codebase it is very hard for anyone new to start helping out. I have tried to look into a few issues I have myself and just cannot get my head around it.

The mentioned "exhaustive" list of issues probably comes from that. Not enough developers and hard for newcomers to start contributing. Everything that makes this easier would be a great benefit and refactoring certainly could make things clearer.

@art4 @Hypolite Petovan @Michael Vogel

@art4 @Hypolite Petovan @Michael Vogel
Als Antwort auf art4

Michael Vogel
Michael Vogel
• •
@art4 @Friendica Developers @Hypolite Petovan I don't think that we have any real roadmap. I'm mostly working on the most urging tasks. I see the voting and the moderation as the most important things. Especially the front-end needs a lot of love.
@art4 @Hypolite Petovan @Friendica Developers
Als Antwort auf Michael Vogel

art4
art4
•

@Michael Vogel how are the release names chosen? I assume, they represent the release date in "YYYY.MM" format.

In the roadmap I can see a "2024.09" and "2024.12" version. In one issue even a "2024.10" version is mentioned. Is there a pattern or time schedule (I.e. every 3 month) for new releases?

@Hypolite Petovan @Friendica Developers

@Hypolite Petovan @Michael Vogel @Friendica Developers

Friendica Developers hat dies geteilt.

Als Antwort auf art4

Tobias
Tobias
• •

@art4 The names are Rhizome. We try to aim at quarterly releases, but e.g. at the moment there is a bug with with installer that does not work properly and this blocks the next release.

Usually we have one release for X-Mas, before most of the devs vanish for the rest of the year to Chaos events or the family. Chemnitzer Linux Tage in March has also hosted plenty releases so far. Then one early during summer and one late summer.

The milestones are collections of things that get fixed or at some point of the development for the one of the devs sees as important enough that they should get fixed soon.

@art4
Als Antwort auf Tobias

art4
art4
•

Thank you very much for all answers so far. As a newbie it is hard for me to read all sources like website, wiki, forum and code repository.

That's why I recommend to have this information near the code in the repository, maybe inside the CONTRIBUTION.md. Imho this would be the best place for developers. The wiki and website should be focused on the users.

Friendica Developers hat dies geteilt.

Als Antwort auf art4

Michael Vogel
Michael Vogel
• •
@art4 @Hypolite Petovan @Friendica Developers concerning refactoring, I guess it is the best to first tell here about what you would like to change.
@art4 @Hypolite Petovan @Friendica Developers
Als Antwort auf Michael Vogel

art4
art4
•

@Michael Vogel

Some first thoughts are:

  • fix composer autoloading warnings
  • improve composer autoloading in dev getcomposer.org/doc/articles/a…
  • introduce static code analysis with PHPStan (min. level 2)
  • improve unit tests and mocking (they should run without database or other dependencies)
  • replace (if possible) assertEquals() with assertSame() in tests

This will show us the places that need urgent refactoring. It will improve the parameter and return types and might fix many PHP notices/warnings/errors.

@Hypolite Petovan @Friendica Developers

@Hypolite Petovan @Michael Vogel @Friendica Developers

Friendica Developers hat dies geteilt.

Als Antwort auf art4

Michael Vogel
Michael Vogel
• •
@art4 @Friendica Developers @Hypolite Petovan this sounds like a reasonable plan. Since you introduced yourself, I possibly should do this as well. I'm no professional PHP developer. I'm working with a different language at work which isn't object oriented. So on the one side I'm a professional - and a rookie on the other side. I still struggle with some concepts in my friendica.
@art4 @Hypolite Petovan @Friendica Developers
Als Antwort auf Michael Vogel

Hypolite Petovan
Hypolite Petovan
• •
@Michael Vogel @art4 Please don't shortchange yourself, during recent years you've done leaps and bounds under @Philipp Holzer and my supervision while we introduced new programming paradigms and refactoring concepts to you.
@art4 @Michael Vogel @Philipp Holzer
Als Antwort auf art4

Hypolite Petovan
Hypolite Petovan
• •

@art4 @Michael Vogel This list looks similar to the one I made for myself half a dozen years ago, and feels extremely ambitious to me. My advice would be to pace yourself, you're dealing with an extensive codebase with a lot of legacy features.

For example, the local Composer binary cannot be upgraded to version 2 because of our reliance on fxp/composer-asset-plugin that enables us to manage frontend dependencies from Composer as well. No version of this plugin exists for Composer 2 and the author has been redirecting people towards one of his more recent projects that inverts the hierarchy by making Composer dependencies available from npm (if I understood correctly).

Similarly, over the past 5 years, I've done some static code analysis and fixed hundreds of warnings using PHP Scrutinizer but I had to stop because of the false positives (see github.com/friendica/friendica…). Similarly, PHPStan will not be happy with many of the remaining legacy files (mainly in the mod/ folder).

Database-less tests would be great, I wouldn't have any idea where to start. @Philipp Holzer did a great job creating the current test framework but any improvement is welcome.

@art4 @Michael Vogel @Philipp Holzer
Als Antwort auf Hypolite Petovan

Michael Vogel
Michael Vogel
• •

Problem is that the support for Composer 1 will end next year. So we need to do something there. I'm completely lost here.

Concerning the mod files: I think that it should be possible to transform the remaining 7 files without too much problems. Except from photos.php most other are relatively small.

Als Antwort auf Michael Vogel

Hypolite Petovan
Hypolite Petovan
• •

@Michael Vogel @Philipp Holzer @art4 And item.php?

I'm with you for the replacement of the Composer plugin. I don't want to go back to bundling the frontend libraries with the code, but I have little to no experience with npm or webpack as a replacement.

@art4 @Michael Vogel @Philipp Holzer
Als Antwort auf Hypolite Petovan

Michael Vogel
Michael Vogel
• •
I refactored item.php several version ago to a level that now the functions are cleaned up. It shouldn't be a problem anymore.
Als Antwort auf Michael Vogel

art4
art4
•
We should tackle one task after another. The composer v1 is one problem (with a PR for review) we have to solve now. The bower dependency, the possible usage of npm, and the refactoring of the mod folder are another problems.

Friendica Developers hat dies geteilt.

Als Antwort auf Hypolite Petovan

art4
art4
•
This list looks similar to the one I made for myself half a dozen years ago, and feels extremely ambitious to me. My advice would be to pace yourself, you're dealing with an extensive codebase with a lot of legacy features.

Don't worry, I'm doing this for many years now and I love it. The trick is to establish processes to reach an minimum code stability. New code must reach this minimum standard and old code can be improved step by step. PHPStan makes this easy with little gamification to reach the "levels" starting with 0.

or example, the local Composer binary cannot be upgraded to version 2 because of our reliance on fxp/composer-asset-plugin that enables us to manage frontend dependencies from Composer as well. No version of this plugin exists for Composer 2 and the author has been redirecting people towards one of his more recent projects that inverts the hierarchy by making Composer dependencies available from npm (if I understood correctly).

No problem, I already created a PR for this problem: github.com/friendica/friendica…

Similarly, over the past 5 years, I've done some static code analysis and fixed hundreds of warnings using PHP Scrutinizer but I had to stop because of the false positives (see github.com/friendica/friendica…). Similarly, PHPStan will not be happy with many of the remaining legacy files (mainly in the mod/ folder).

I already started the refactoring with PHPStan level 0, see github.com/friendica/friendica…

About the folder "mod" and "mods" I'm sure we will find a way to move them into the "src", "view" and other folders.

Database-less tests would be great, I wouldn't have any idea where to start. @Philipp Holzer did a great job creating the current test framework but any improvement is welcome.

The given tests are a great start for me improve and to familiarize myself with the code. I already have some improvements for the tests in mind.

@Philipp Holzer

Friendica Developers hat dies geteilt.

Als Antwort auf art4

Hypolite Petovan
Hypolite Petovan
• •

@art4 Thank you so much for the work you've already done!

Small precision: the "mods" folder is independent and doesn't have included PHP code in it. It includes suggested configuration files and a bookmarklet example.

@art4
⇧