Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
FreshRSS community processes #789
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
And… that's all! Thanks for reading :)
Here are some quick thoughts
General community process
With Travis and PR it's for the best
There is a lot of logic to move out of controllers to have components. Idem for models. cc @aledeg
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'
@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.
There are two mailing lists available at freshrss.org/mailman/listinfo:
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.
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 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.
PHP5 usage statistics:
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+.
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).
Maybe a discourse can be both the forum, the mailing list and a decision tool like loomio?
It's an idea :)
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.
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"?
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 :)
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:
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:
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.
referenced this issue
Dec 17, 2017
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.
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.
@aledeg Ouh, this is the type of discussion, which would be better around a table :-)
Meta comment first: many of those aspects boil down to:
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:
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).
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. :-)