Friendica Developers reshared this.
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?
This entry was edited (1 month ago)
like this
art4 reshared this.
You can solve sudokus in python packaging.
Not not python code, python packages:
```
[project]name = "sudoku"
version = "1.0.0"
dependencies = [
"sudoku_3_1 == 2",
"sudoku_5_7 == 6",
"sudoku_0_7 == 5"
...
]
```
and the installed packages are the solution.
github.com/konstin/sudoku-in-p…
GitHub - konstin/sudoku-in-python-packaging: Sudoku solving in python packaging
Sudoku solving in python packaging. Contribute to konstin/sudoku-in-python-packaging development by creating an account on GitHub.GitHub
This entry was edited (1 month ago)
art4 likes this.
reshared this
Tobias
in reply to art4 • • •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 likes this.
Hypolite Petovan
in reply to art4 • • •@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 likes this.
art4
in reply to Hypolite Petovan • • •Thank you.
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.
Michael Vogel
in reply to art4 • • •art4
in reply to Michael Vogel • • •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 l
... show moreThank 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.
AndiS 🌞🍷🇪🇺
in reply to art4 • • •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 likes this.
Michael Vogel
in reply to art4 • • •art4 likes this.
art4
in reply to Michael Vogel • • •@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
Tobias
in reply to art4 • • •@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 likes this.
art4
in reply to Tobias • • •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.
Michael Vogel
in reply to art4 • • •art4
in reply to Michael Vogel • • •@Michael Vogel
Some first thoughts are:
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
Michael Vogel
in reply to art4 • • •art4 likes this.
Hypolite Petovan
in reply to Michael Vogel • • •art4 likes this.
Michael Vogel
in reply to Hypolite Petovan • • •alfredb
in reply to Michael Vogel • • •@Hypolite Petovan @Philipp Holzer @art4
art4 likes this.
Hypolite Petovan
in reply to art4 • • •@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-pluginthat 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
... show more@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-pluginthat 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.
Michael Vogel
in reply to Hypolite Petovan • • •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
modfiles: I think that it should be possible to transform the remaining 7 files without too much problems. Except fromphotos.phpmost other are relatively small.Hypolite Petovan
in reply to Michael Vogel • • •@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.
Michael Vogel
in reply to Hypolite Petovan • • •item.phpseveral version ago to a level that now the functions are cleaned up. It shouldn't be a problem anymore.art4 likes this.
art4
in reply to Michael Vogel • • •art4
in reply to Hypolite Petovan • • •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.
No problem, I already created a PR for this problem:
... show moreDon'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.
No problem, I already created a PR for this problem: github.com/friendica/friendica…
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.
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.
Hypolite Petovan
in reply to art4 • • •@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 likes this.