Simple question

hello everyone
sorry but I’ve been asking myself this question for days that I can’t find an explanation, and I wanted to share it with you
here on the forum lately I’ve seen some small changes that I think are interesting for IPFire, the filter for the connections.cgi page comes to mind or the RPZ engine where many users have tried it and given their feedback on how it works
I was wondering why they aren’t integrated into the system if not as native components like pakfire
I want to point out that mine is a simple question NOT intended to be controversial but arises only out of curiosity if there is a technical reason or something else

1 Like

Good and healthy question.

I believe (in my opinion) that it’s because for something to be integrated that isn’t maintained by the IPFire team, the developer must commit to its maintenance. Without that commitment, proper functioning over time isn’t guaranteed.

This happened with an add-on that was created to send reports, which was very good, but the person who developed it stopped maintaining it. Now that add-on works as it does.

Sorry for my poor English.

That’s what I believe, without getting into controversy.

Saludos.

This modification also remained in limbo:

Saludos.

Roberto, thanks for your opinion, I understand what you say, but let me make a consideration that I made on my own before making my post, just to understand better.

Let’s take for example the file connections.cgi where a user posted the modified file and the same one tried by some users where the same one works well, obviously I am aware that it is not always like this for all the components provided by the community

Replacing it with the standard one is the step is minimal and on the part of the team I would say very close to zero, then the investment for maintenance is the same as the current one.
so replacing it does not involve investment or hours of work, and a better tool is provided than the current one

Any patches for submission of changes should be sent to the developers mailing list as described in the IPFire documentation.

That has not yet occurred for one of the patches that you mention.

Once a patch or patch set has been submitted then it needs to be reviewed and that involves an interactive discussion with regard to any questions that are raised.

With the second patch set you mention that interaction had been started but it seems to have stalled for the last 7 or so weeks.

4 Likes

thanks Adolf for the precise and detailed answer, but allow me to express my thoughts and such must be.
I understand the motivation and the path described in the documentation to make a component official, but I think that some changes posted on the forum by the community if one of the team acts as a spokesperson would streamline the path and the work for the whole team
the only one who gains from this is only the IPFire project but maybe I’m wrong

I think that the spokesperson for any patch/patch set being submitted needs to be the person who did the work creating it.

Other people who just have a quick glance over the code in the forum are not going to be well placed to explain why certain decisions were made or how easy it would be to change the code to match up with the IPFire code requirements or accepting to modify the code to match up with security issues that have been identified.

However if there is someone from the forum willing to take up that role then they can always pick it up but whoever does it cannot act in a man in the middle role. They have to act as the owner/developer of what is being presented and committed to supporting/correcting on an ongoing basis.

5 Likes

Ciao Adolf, thanks for your reply and for the clarification, I must also say that I fully agree with what you have stated and with the guidelines.
But let me make a distinction just to be clearer, for this I always take the two examples I mentioned in the first place
For the RPZ component I would say that the reasoning you have exposed is correct and regular and I would not change anything, but if I take the other example of modifying the connections.cgi file I think it is more profitable for everyone to be more flexible and that the team takes charge of the modification.
As said it is only my opinion and as such it must be

1 Like

I think the two examples are distinct ‘classes’:

  • the connections.cgi is a modification to existing software modules; there are some devs which are able to review quickly and maintain this part.
  • the RPZ theme introduces a new functionality to IPFire; maintanance must be assured, knowledge isn’t really widely present in the devs community.

BR,
Bernhard

1 Like

Hi all,
am thinking about that some testings like introduced also in e.g. here Is there any benefit to a HTTP-only proxy? - #11 by ms are a good way to

  • Overcome problems/bugs which the developer simply have overseen.
  • Deliver a better feeling for a push with a possible merge request.
  • Brings up also some other ideas/simplifcations and formost.
  • If there is any interest/feedback in this topic by the community.

Spoken for myself, that´s the way i want to double check but also to share my contributions. If there is no interest, i am good to go by my own since i develope stuff which i´ am interested in and wanted to use it too. But that´s only my two cents on this topic.

Best,

Erik

2 Likes

what I mean, that there are some changes to the system that should follow a very specific procedure, and whoever made the change should take charge of it.

but other changes should only be exposed and the team should take charge of them

I think it’s crazy that modifying the connections.cgi file that inserts the search and the filter, that whoever made the change and made it available to the community should guarantee to commit to supporting/correcting it constantly.

Modifying existing WUI source files are modifications to more or less known code of the dev community.
Adding a new functionality like RPZ in unbound means activating code in programs taken from external sources. Usually this SW is tested more in a black box manner. The internals are not known really. And the development doc of a complex software product is complex also.

Dear @tratru

to answer your question a little wider, there are two possibilities in here Search and filtering in connections.cgi
, one should be close to the current and already existing connections.cgi → https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=d5dc6a36324a7d7a5a067689f51d25ab3d10e026 the other one (which i really do prefere for myself) includes a lot more “specific procedures” git.ipfire.org Git - people/ummeegge/ipfire-2.x.git/commit which i do understand is a problem to follow up in a, at least, four eyes principal. Wanted nevertheless to bring it up, at least for the community since i think it is a novum to have a refresh interval in IPFire´s WUI.
Also, a lot of possible development comes up from people of the community and i think it is may also a good move to keep topics like this alive to bring on not only the problem solution topics (which is the essence of this forum) but to support also another kind of thinking and the fun of create something or at least to see that something is possible :wink: .

So i hope (your may retoric) question of “whoever” can also be answered :slight_smile: .

Best,

Erik

2 Likes