Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FreshRSS community processes #789

Open
marienfressinaud opened this Issue Feb 9, 2015 · 26 comments

Comments

Projects
None yet
6 participants
@marienfressinaud
Copy link
Member

marienfressinaud commented Feb 9, 2015

Hi all!

I have worked a bit on some important processes to be more « community-friendly ». Here are the points I wanted to discuss. It is a bit long, but it is important for the future of FreshRSS ! :)

General community process

  • A mailing list could be great to communicate between developers and users
  • I have to finish the CONTRIBUTING file
  • I thought to move all the *.freshrss.org domains on a dedicated VPS to be able to give access to some trusted contributors. It also means it will cost more money to me so it will probably wait until I have a new job ;)
  • The new doc (https://github.com/FreshRSS/documentation) has to be installed. daux.io does not support image hosting as I would like so I'll have a look at couscous.io (used by wallabag): we can keep our current doc files, only internal links will have to be updated if we choose to use this doc software.
  • Do we need a forum? It seems to me that if we have a mailing list, we don't need a forum.
  • What do you think of using Loomio for taking important decisions? Or the mailing list is enough?
  • I wanted to create a sort of schema or map to explain to users who want to contribute, where they should begin.
  • And a simple question but hard answers I guess: who own the code? I mean, when I was alone to work on FreshRSS, it was easy, I owned the code. But since people can contribute, it's harder to say. Do we need a sort of « collaboration agreement »?

Internationalization process

  • We have to update i18n.freshrss.org, at least to explain to not use it!
  • CONTRIBUTING file has to explain in few steps how to participate to the i18n
  • I think a new string must have, at least, an English version. Other versions (French, German and future supported languages) can use the English version in a first time if contributor don't know the correct translation.
  • We'll need later a developer script (e.g. i18n.php) to manipulate translations (e.g. to add a sentence, to rename a key). For now it's ok since we have to take care of only 3 languages.

Quality process

  • Use a view template system to have a better MVC architecture separation and facilitate theme contributions
  • Considerations about a new, supported and documented PHP framework:
    • Clearly, it's not realistic to entirely rewrite FRSS with a new framework BUT…
    • … we have to improve some controller and model source code by reducing the longest methods and think a bit more to the framework logic (ping @dhoko ;))
    • Comments and code documentation are necessary too
    • I would like to release a new proper version of Minz
  • Tests + Travis integration are welcomed (@aledeg has already begun, thanks!)
  • Improve documentation
  • Reduce size of the README: it's quite a complete documentation page actually
  • Improve FreshRSS update process: I always face problems when I release a new version. First step will be to document how to release a version! Next step will be to have a test environment.
  • JavaScript code is really too complex to maintain or to understand. We will have to rewrite all of it I think. Has someone some strong knowledges or advices to write nice JavaScript code?
  • I really want to improve the contribution process. This point is really important to read for @Alkarex and @aledeg!
    • I would like to avoid direct commits on the dev branch
    • Instead, always open a pull request (PR) so we can review the code
    • A PR must be self-documented and tested. For instance, if you add a new feature, don't forget to document the new code, add a line in the CHANGELOG and add some tests.
    • Before merging a PR, I would like at least two persons read the PR. If it is an new collaborator, @Alkarex, @aledeg or me can merge the PR. If it is one of us, please wait to be reviewed by someone else before merging.
    • The best would be PR are always merged by a person different from the one who opened the PR.
    • These rules should apply for new features or even for bug resolutions (even for a one-line commit)
    • I know it is a lot of constraints (it is for me at least!), but it is to improve code review and so the global quality. It is actually the way Diaspora* team works.
    • Since we are not always available to review code from the others, I can understand if you prefer to keep the old way! But if the community grows up one day, I would like to keep in mind this process.
  • I would like to change AGPL3 license by a MIT license. What do you think about that?
  • Support Composer (use with extensions too)
  • Change official supported PHP version
  • Support namespaces

Communication process

  • We need a dedicated blog. I think to install a Wordpress: easy, powerful, supported. Or use a static site generator (e.g. Pelican) to generate both website and blog. Bonus: pages and articles could be hosted in a Git repository.
  • Articles will be in English, it could be great to have someone to correct them if there are too many mistakes. My English is understandable (I think) but my vocabulary, expressions and grammar are « limited » :-/.
  • Update the website
    • Change email contact with the mailing address (please don't use my email address to ask me questions about FreshRSS!)
    • Remove Flattr button
    • Add a link to the blog and Twitter account / tag
  • I may give access to the Twitter account to some of us. Tell me if you want but in that case we will have to set up some usage rules.
  • I wanted to write an article on LinuxFR to speak about FreshRSS and its « community openness » but not before having mailing list and the CONTRIBUTING file finished.

And… that's all! Thanks for reading :)

@aledeg

This comment has been minimized.

Copy link
Contributor

aledeg commented Feb 9, 2015

Here are some quick thoughts

General community process

  • I think mailing lists are enough. Maybe one for users and one for devs.
  • I already pay for a hosting with dreamhost. I can have it hosted on my instance. I already have a couple of things on it. I also can host mailing lists.

Internationalization process

  • I think we need tools as well to manipulate i18n. Search for new strings, renaming strings, flagging modified strings

Quality process

  • I am looking forward to use a templating engine. That will help reuse code. This weekend, I was modifying the stat page and a trash my code because it was too ugly.
  • The tests I started are the easiest for now. But I think there is a need for a huge refactoring to make it efficient. For instance the use of static in the context object is a way to implement globals in an object. I would rather instantiate an object for each query and use dependency injections in other objects.
  • You are right with the README. Basically, we need only a short explanation of FreshRSS, a link to the demo, the doc, and Twitter account.
  • Yes we need a Javascript guru to guide us. Any volunteer.
  • I agree with you with the code review. It will be better for all of us.
  • MIT is fine by me
@dhoko

This comment has been minimized.

Copy link

dhoko commented Feb 9, 2015

Quality process

  • Add PHP-CS-Fixer to use PSR1|2 coding standards
  • Add jshint to lint JavaScript
  • Add tests for JavaScript and PHP
  • Add PHPDoc and JSdoc for the API

With Travis and PR it's for the best 🍻

… we have to improve some controller and model source code by reducing the longest methods and think a bit more to the framework logic

There is a lot of logic to move out of controllers to have components. Idem for models. cc @aledeg

Since we are not always available to review code from the others, I can understand if you prefer to keep the old way! But if the community grows up one day, I would like to keep in mind this process.

A PR can wait more than a month before a merge. It's an open source project, people can understand.

There is a lot of work to do. I'm working with an extension to build a REST API, I cannot use FreshRSS code because it's 'spaghetti' 🎳

@marienfressinaud

This comment has been minimized.

Copy link
Member Author

marienfressinaud commented Feb 11, 2015

@aledeg > I also have a hosting (VPS with OVH), it's not a problem. I just want to dedicate a VPS or server to FreshRSS to separate it from my other services.

Ok for the two mailings, I will have a look at them this morning.

@dhoko > thanks for your reply! I think I will follow a real analysis process before going further and will share my thoughts about that. Tests, coding style and documentation must definitely being part of the standard development process.

@marienfressinaud

This comment has been minimized.

Copy link
Member Author

marienfressinaud commented Feb 11, 2015

There are two mailing lists available at freshrss.org/mailman/listinfo:

  • mailing@freshrss.org is destined to users and usual questions about FreshRSS. It should be the entry point for users ;
  • dev@freshrss.org is mostly destined to developers and is more technical.

Both are opened to everyone.

I hope it will work fine: mailman was previously configured with another domain and I don't know how it supports two domains.

@dhoko

This comment has been minimized.

Copy link

dhoko commented Feb 11, 2015

As I need to rewrite a lot of things I will try to do some PR if I can. (But i do not support < PHP 5.3).

@marienfressinaud

This comment has been minimized.

Copy link
Member Author

marienfressinaud commented Feb 11, 2015

It may be the time to change the official supported PHP version ;). Also, I want to support composer. I will add these points in my first post.

@dhoko

This comment has been minimized.

Copy link

dhoko commented Feb 11, 2015

Yeah :) I cannot write PHP without it. Do you plan to add namespaces too ?
If you support composer, I think it's a good idea to use it for extensions.

@marienfressinaud

This comment has been minimized.

Copy link
Member Author

marienfressinaud commented Feb 11, 2015

If the goal is to have a source code as perfect as possible, yes, I plan to add namespaces ;). But it's still open to the discussion (like the other points). But it is definitely a great idea.

@aledeg

This comment has been minimized.

Copy link
Contributor

aledeg commented Feb 11, 2015

I agree with php5.3, We should get rid of it. I guess now most of the hosting provider support at least 5.4. Mine support 5.3 (sic), 5.4, 5.5 and 5.6.
Getting the thing together with namespace and composer would be really neat

@Alkarex

This comment has been minimized.

Copy link
Member

Alkarex commented Feb 11, 2015

For reference:
In the Debian/Ubuntu family, the current oldest Ubuntu LTS (10.04) uses PHP 5.3.2 http://packages.ubuntu.com/lucid/php5 . When it stops in April, the oldest Ubuntu LTS will be 12.04 with PHP 5.3.10 http://packages.ubuntu.com/precise/php5 with support until April 2017. The newest Ubuntu LTS (14.04) uses PHP 5.5.9 with support until April 2019.

In the Fedora/RedHat/CentOS family, the current CentOS (7) uses PHP 5.4.16, and the previous version (CentOS 6, full updates until Q2 2017) uses PHP 5.3.3.

The oldest PHP version on OVH shared hosting (largest hosting provider in Europe) is currently PHP 5.3.29 http://90plan.ovh.net/infos/

PHP namespaces require PHP 5.3+, with several namespace-related bugs corrected in PHP 5.3.3.

We have some special code to handle bugs in PHP < 5.3.3, e.g. https://github.com/FreshRSS/FreshRSS/blob/beta/lib/lib_rss.php#L62 , which could be removed if we drop such old versions.

We have some special code to handle missing features in PHP < 5.3.4, e.g. https://github.com/FreshRSS/FreshRSS/blob/beta/lib/lib_rss.php#L106 , which could be removed in the future if we drop such old versions.

It would be nice to have FTS4 in SQLite, which appears with PHP 5.3.6 #100 (comment)

We make use of password-related functions, which require PHP 5.3.7+ http://php.net/intro.password , https://github.com/ircmaxell/password_compat

We have some special code to handle minor missing features in PHP < 5.4, e.g. https://github.com/FreshRSS/FreshRSS/blob/beta/app/views/helpers/export/articles.phtml#L42 , which could be removed in the future if we drop such old versions.

The current oldest PHP Old Stable is 5.4.37 http://php.net/downloads.php . Older version are not maintained anymore by the official PHP community. PHP 5.3.x is not supported anymore since August 2014.

PHP Opcache is shipped with PHP 5.5+ http://php.net/opcache and in my case, it provided a significant performance boost on my modest Kimsufi server #124 (comment)

PHP5 usage statistics:
http://w3techs.com/technologies/details/pl-php/5/all (~20% PHP < 5.3 as of February 2015)
http://blog.pascal-martin.fr/post/php-versions-stats-2014-10-en.html (~29% PHP < 5.3 as of October 2014)

IMHO, it would be fine to require PHP 5.3+ now, and even 5.3.3+ (released in July 2010) or 5.3.7+ (August 2011), especially after April (end-of-life of Ubuntu 10.04 LTS using PHP 5.3.2), and in any case recommend PHP 5.5+.

@dhoko

This comment has been minimized.

Copy link

dhoko commented Feb 11, 2015

Yup php 5.3 is dead, support can start from PHP 5.4. Debian provides PHP 5.4.36 cf https://packages.debian.org/stable/devel/php5-dev

@marienfressinaud

This comment has been minimized.

Copy link
Member Author

marienfressinaud commented Feb 11, 2015

Thanks @Alkarex for this summary!

Moreover, for those who don't have PHP >= 5.4, they still have the possibility to use FRSS 1.0 which should be maintained for security reasons on a long period (even if we release version 1.2, 1.4, etc.).

@Alkarex

This comment has been minimized.

Copy link
Member

Alkarex commented Feb 11, 2015

Shorter version of what I wrote above : there are good technical reasons to require PHP 5.3+ for the core FreshRSS, or PHP 5.3.7+ for some optional features (SQLite, password access). There is still a large user base with PHP < 5.4 (~65%) including popular and supported Linux server distributions such as Ubuntu 12.04 LTS, CentOS 6, Synology DSM 4.x. Furthermore, we have not yet mentioned the need of any feature of PHP 5.4+ (besides Opcache with PHP 5.5+). So dropping PHP 5.3 would lock out ~45% of users without real reason (so far).
Therefore, I suggest requiring PHP 5.3+ (or 5.3.3+) for the core FreshRSS, and higher versions for optional features.

@Flaburgan

This comment has been minimized.

Copy link

Flaburgan commented Feb 11, 2015

I thought to move all the *.freshrss.org domains on a dedicated VPS

Maybe framasoft can help you there?

@Flaburgan

This comment has been minimized.

Copy link

Flaburgan commented Feb 11, 2015

Do we need a forum? It seems to me that if we have a mailing list, we don't need a forum.
What do you think of using Loomio for taking important decisions? Or the mailing list is enough?

Maybe a discourse can be both the forum, the mailing list and a decision tool like loomio?

@marienfressinaud

This comment has been minimized.

Copy link
Member Author

marienfressinaud commented Feb 11, 2015

@Flaburgan

Maybe framasoft can help you there?

It's an idea :)

Maybe a discourse can be both the forum, the mailing list and a decision tool like loomio?

For the moment I think we'll try with the mailing lists and then, if it doesn't work, we'll see for another solution.

@marienfressinaud

This comment has been minimized.

Copy link
Member Author

marienfressinaud commented Feb 11, 2015

We'll have a problem with the development process: if I want to apply the new way, I'll have to fork the repo FreshRSS/FreshRSS to marienfressinaud/FreshRSS which is… the previous official repository! It means redirections will not work anymore. Can we consider people will understand my repo is not the official anymore? Or is it too "risky"?

@aledeg

This comment has been minimized.

Copy link
Contributor

aledeg commented Feb 11, 2015

You can also push on one branch on the current repository and ask for a PR on the dev branch. You don't need to use a different repo. I already done that a couple of time.

@marienfressinaud

This comment has been minimized.

Copy link
Member Author

marienfressinaud commented Feb 11, 2015

True (that's what I've done for CONTRIBUTING file by the way) but I would to keep the official repository clean of additional branches, especially if it's for a "one-commit patch".

@aledeg

This comment has been minimized.

Copy link
Contributor

aledeg commented Feb 11, 2015

Maybe you can create a copy with a different name.

@marienfressinaud

This comment has been minimized.

Copy link
Member Author

marienfressinaud commented Feb 11, 2015

I tried (https://github.com/marienfressinaud/FreshRSS_PR) but now https://github.com/marienfressinaud/FreshRSS is redirecting to the new repo :(

Edit: I will keep the repo but add a message

Edit 2: good news, the bug tracker is disabled on my fork so it will reduce tentatives to contribute to my fork :)

@Alkarex

This comment has been minimized.

Copy link
Member

Alkarex commented May 16, 2015

A little feedback after having tried the new guidelines: it of course makes sense to make pull requests, having them reviewed by several persons, and merged by someone else.

However, this requires that several of us are active during the same periods, which historically has not really been the case for FreshRSS (and I do not think it is a problem, quite the contrary). Therefore, here is in a few words what I have done:

  • I have done some pull requests for almost every change. Except for some reverts, and a few minor things.
  • First, I have waited for a few pull requests to be processed, more than one month, but then I ended up merging them myself (after testing). I did that because when the pull requests are waiting, they are not in /dev and it is my impression that we have several users of /dev, but close to none testing the pull requests (which is understandable, as it is a much heavier process). Furthermore, if there are several open pull requests, we end up with merge conflicts and other dependency problems.
    • There were also a couple of mistakes when I accidentally merged in /dev instead of my own repository. It would have been possible to revert.

My feeling is that we need to keep some flexibility to ensure that we can easily push FreshRSS forward. When there is a user reporting a bug, it is important that when we have a solution, it is quickly landed in /dev, because we cannot expect many users to test pull requests. It is already nice to have testers for /dev, and I do not think we should ask much more. It is always possible to revert or make additional corrections in /dev afterwards.

Therefore, I am advocating for:

  • Making pull requests for most things, but not for trivial ones.
  • Merge the pull requests in /dev quite fast, best after a review, but otherwise after an amount of time depending on the complexity/consequences of the pull request: wait a few days for a basic improvement, but allow more time for a larger change that may be controversial, especially if there is an ongoing conversation. If it is a correction of a critical bug, then I believe it is OK to merge it even faster.
  • If it was not possible to do before, then review the changes when time permits, after they are merged in /dev. As written above, it is always possible to revert or further patch a merged contribution.
  • Use the /beta process to concentrate testing efforts.

I am personally using the /dev branch for my own FreshRSS instance, which I use intensively, so I have a personal incentive on keeping the /dev branch functional. More precisely, I use the /dev of my own repository in which all my own pull requests are immediately merged.

In conclusion, I think it is important that we allow keeping the speed on /dev, and we can use the /beta and /master processes to test more and more extensively.

Alkarex referenced this issue Jun 3, 2015

Refactor exceptions
I removed unnecessary constructors and unnecessary inheritance

@marienfressinaud marienfressinaud referenced this issue Oct 12, 2015

Open

Future of FreshRSS #995

28 of 65 tasks complete

Alkarex added a commit to Alkarex/FreshRSS that referenced this issue Jul 30, 2016

Update MySQL to utf8mb4 (full unicode) 🔥
* Requires MySQL 5.5.3+ (drop support for MySQL 5.0)
* Requires PHP 5.3.3+ (drop support for PHP 5.3.0)
FreshRSS#789 (comment)
@aledeg

This comment has been minimized.

Copy link
Contributor

aledeg commented Feb 24, 2019

Reviving this old issue. At the moment, I feel like the core needs to be changed. Not for the sake of changing but to ease development and to add new features.

First, I think we should drop the support for all the unsupported PHP version. Maybe not in the 1.x branch but on a 2.x branch. At the moment, only PHP 7.1 and higher are supported. I think that we should drop support for all the previous versions. Dropping the support on a new branch doesn't mean that the 1.x branch wont work anymore, but that we only patch it for security issues.

Second, I think we should stop using Minz. It was a good way of abstracting all the calls from FreshRSS, but I think that now we should use something that is widely spread and well maintained. I am thinking about Symfony components but that could be anything that have more that a handful of maintainers. With that in mind, we could have access to dependency injection, events, subscribers, listeners, commands and many more things.
If we go that way, we can focus on what is really important (features) and not on the underlying technique. This will allows us to provide in a simple way, APIs (REST, greader, graphQL, ...), templates, plugins, automated tests (phpunit & behat)...

I've been think of this for a long time but it hits me hard yesterday when I started working on automated filters on feed update. It will be hard and painful to do that with the actual code base but so easy with a modern architecture. That's why I stopped :(

My rant is over. Let me know what you think.

@Alkarex

This comment has been minimized.

Copy link
Member

Alkarex commented Mar 3, 2019

@aledeg Ouh, this is the type of discussion, which would be better around a table :-)
Many points...

Meta comment first: many of those aspects boil down to:

  1. what market niche do we want for FreshRSS - there are indeed several other RSS readers with other priorities / target groups. See e.g. NextINpact series of articles. Or in other words, why do our users pick FreshRSS instead of something else. I have of course an opinion on that, and some anecdotal evidence, but no hard data.
  2. developer human power - whatever change is introduced has an impact on development efforts, not only to implement the changes, but - at least as important - to support them over time.

PHP versions: let's not confuse the upstream development efforts with the actual long-term support in distributions and devices. The PHP 5 branch is very well supported, for several more years. Just one example: CentOS with PHP 5.4.16 will be supported until June 2024. PHP 5 is not only still there, but dominant. Please see higher up in this thread for more precise answers on this specific point. We have regularly dropped older PHP versions due to technical reasons difficult to work around, and I believe we should continue doing so at a slow pace, but I generally see any drop in back-compatibility as a minus, not as a plus. So this is a balance. Dropping back-compatibility contributes to premature obsolescence and makes user's life more complicated.

Minz: I am not in love with Minz, but it has the advantage of being lightweight (30 files, 78KB), which is compatible with the market niche that I see for FreshRSS. One can read and understand Minz within minutes. On my side, I have never thought: « Oh I wish we had feature X, which we cannot do without embedding the full framework Y. » Indeed, changes to add or tweak whatever feature are done with little efforts and in a very native / standard way. Latest example to date: adding the ability to receive POST data in JSON:

/**
* Allows receiving POST data as application/json
*/
private static function initJSON() {
$contentType = isset($_SERVER['CONTENT_TYPE']) ? $_SERVER['CONTENT_TYPE'] : '';
if ($contentType == '') { //PHP < 5.3.16
$contentType = isset($_SERVER['HTTP_CONTENT_TYPE']) ? $_SERVER['HTTP_CONTENT_TYPE'] : '';
}
$contentType = strtolower(trim($contentType));
if ($contentType === 'application/json') {
$ORIGINAL_INPUT = file_get_contents('php://input', false, null, 0, 1048576);
if ($ORIGINAL_INPUT != '') {
$json = json_decode($ORIGINAL_INPUT, true);
if ($json != null) {
foreach ($json as $k => $v) {
if (!isset($_POST[$k])) {
$_POST[$k] = $v;
}
}
}
}
}
}

When the code is sufficiently lightweight, the maintenance effort is minimal. If anything, I would like to make Minz even more lightweight, in particular by removing several classes that are not really bringing added value (e.g. some custom exceptions instead of just native ones), and by increasing even more the performances (by reducing some superfluous code and with a more just-in-time approach).

Compare that with Symfony 4.x (as an example): 7146 files, 29MB (i.e. about 300× larger, excluding additional modules). One would have to admit that by using something like that, one has no idea of what such a large codebase is actually doing, and of course it requires an army of developers to maintain. If anything in such a framework is not behaving or performing like we want, making changes would be considerably more difficult than with e.g. Minz, and extremely time consuming to maintain over time. Not to mention the problems of updating/upgrading to newer versions of such frameworks. Now, this is for sure very relevant for medium-to-big Web solutions (or small solutions with only little customising), with a lot of middleware needs, in particular with several dedicated developer. There are a number of theoretical advantages, but also some very concrete drawbacks: massive increase of codebase and footprint (and therefore increased security threats), decreased performance (to run, but also to deploy/update), higher barrier for contributors (not only knowledge in vanilla PHP is needed, but also in that specific framework), uncertain and more challenging maintenance over time, risks of embarking in library dependency hell/rot (as encouraged by e.g. Composer deployments), to name a few.

See the counter-example of removing jQuery and the shortcut library, which - I would argue - has reduced the code footprint (also of our own code), made our code more standard and easy to maintain, increased performance, and fixed some bugs (including some, which would have been more challenging to solve if keeping those libraries).

In any case, moving to e.g. Symfony would require a quite large effort, and would likely result in a significantly different product. It could potentially be almost like starting from scratch again. As such, considerations such as changing language completely would also be among the options. We would then have to consider what other existing project this would compete with, and whether it would make sense to make yet another one.

Maybe we could indeed find another ultra-light framework to replace Minz without losing its advantages.

API: There is not much added value with an API, which is not standard. The Google Reader API is the one winning in terms of the number of servers and clients implementing it. Providing yet another API would contribute to more code and more fragmentation, for unclear benefits.

Templates: HTML with PHP is already a fine templating approach ;) Furthermore, anything else based on third-party PHP libraries (i.e. not natively provided by the language) has big performance penalties, and comes with fragmentation and maintenance issues. A side note in our current code base, I would like to make the whole pipeline more streamable from DB to client (which I have already done for some export features, which were otherwise hitting memory limitations) in order to be faster, to use less memory, and to scale better to many clients.

Patching old FreshRSS releases / branches: This is a desirable thing, but also time consuming and in practice, we have never done it. In case of serious bugs, a new release was instead quickly issued. That might be doable if you are able to motivate enough additional maintainers.

Tests: very desirable (if maintained), again mainly a question of finding time, and not so dependent of whether we pick another framework or not.

Automatic filters: Nice feature to get indeed. On my side, the main effort is to conceptualise how this should be: for the user (what is the right balance between expressiveness and ease of use), and for the engine (scalable approach), not on how to code it in details (with or without an additional framework), which I find relatively easy once the concepts are in place. I have been thinking about the concept for a relatively long time, for instance on how to express dependencies to other feeds, and I would love to have discussions on the topic.

Misc.: When it comes to refactoring things, in addition to what I wrote about Minz, I think the i18n language files should be changed (to be more standard and easy to maintain, but without killing performance), and it would be nice to provide an alternative to SimplePie. There are also plenty of things to do on the frontend (e.g. advanced search), which do not really depend on the backend.

So as you can see, I am (for this project) more conservative, attracted by light-weight and KISS approaches, with a focus on defining the concepts before coding (e.g. possibilities offered by WebSub + ActivityPub), and considering our sweet-spot in the larger RSS/news ecosystem.

Closing the loop back to the beginning of this response, many of those points depend on who is (how many are) actually motivated in doing the actual work (also over time), and what our users value in FreshRSS when compared to the several other options (technically and ethically).

@Frenzie

This comment has been minimized.

Copy link
Member

Frenzie commented Mar 3, 2019

I largely agree with @Alkarex, btw.

I don't really have an opinion on Symfony as such, since I have no direct experience with it. The comparison with jQuery makes it sound like unnecessary obfuscation, but jQuery originated as a way of abstracting away mid-2000s browser differences that are no longer relevant. In that sense the comparison presumably doesn't make too much sense.

We already have an MVC model. In that regard it seems that Symfony would just be a difference without distinction. You'd get the advantage of upstream maintenance, provided APIs and such are actually stable. Otherwise that'd very much be a disadvantage. (I imagine one would only pick a few modules, rather than the full 29 MB source, but the point about size likely stands either way. ;-) )

Tests are just a thing I haven't really gotten around to implementing on the CI, but I don't see how that would be affected one way or the other. The FreshRSS code isn't the kind of code that looks like it needs significant refactoring to be testable. We already have a bunch of useful tests to boot; they just don't happen to be executed automatically yet.

The clean design of its code compared to, e.g., tt-rss and how easy I found it to understand is actually one of the main reasons I went with it. Something potentially obfuscated by some complex framework may not be something I'd have chosen. That quite literally describes another alternative I evaluated that was functionally equivalent or better — I'm just not sure otoh if it was Symfony. It was, however, more difficult to set up, more difficult to understand, and slower.

Insofar as there's anything I want to add to the program in the near long term, for me personally that's primarily in HTML+CSS and some supporting JS. You can already do quite a bit with the CustomCSS and CustomJS extensions alone. Sure, there's the occasional bit backend support required as well, but to me the PHP backend is mainly a matter of the occasional bug fixes and other maintenance.

Of course I'm not against someone rewriting half the program, provided there's a decent rationale. I'm just not interested in it myself. Because if I were, I probably would've done just that instead of going with FreshRSS. :-)

@Alkarex

This comment has been minimized.

Copy link
Member

Alkarex commented Mar 3, 2019

A more fair comparison with something from another language would be e.g. Java Spring

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.