Hello,

I am actually at a point now where I think we need to talk about this. A lot.

So many people have been starting to contribute to this project - or as I sometimes see it - to parallel projects. Projects that are developed in parallel to the main distribution. Projects that have different goals or are at least from my perspective heading into a different direction.

The mail proxy/mail server/web mail project is one like these. There are also others like multiple versions of the update accelerator and some more.

These changes are never submitted on here. There is not even a conversation on here about that being a goal. Despite me having multiple chats with people about how this process works and that they want to do it, soon-ish.

So here we are. Months later. With no progress at all.

Instead I am getting requests and bug reports for that software that I am not involved with at all. People tell me that bugs are fixed there or that there are features available they want to use. They ask when this will be available in the distribution.

I don't have an answer to that. And what is even worse is that right now I am too tired to look into this.

These projects have diverted a lot in that sense that an easy merge is no longer possible. It will take a lot of work to split up the changes, test them, confirm that they work, do QA and then release them. This process itself is not foolproof and we are not getting a lot of feedback. We just get the backlash when something is not working properly. It will be very tough.

Working on these changes step by step would have certainly avoided getting to this state. Now we are at it. Frankly, I do not know what to do.

I will certainly not sit down and take these things apart myself. I have actually not much interest in working on these things any way. Cleaning up after somebody else won't be my main job for the next few weeks. That is partly because I don't want to and partly because that won't work any way. It is not my code.

The other option would be just to leave these projects as they are. That may either be getting old and rot in a git tree. That may either be them becoming something else. But I do not think that any of these is the best option for the IPFire project as a whole. I am very much interested in keeping that as the main target of my work.

And that might me or other IPFire developers to do the same work again. In this specific example update apache. From my point of view that only wasted valuable developer time. In both projects. That can't be the ideal.

So I would like to hear that from the people who are working on these parallel projects what they are intending to do and what they are expecting from me/the other developers. I honestly do not know if you think yourself that this is an issue, too. So let's have a productive discussion about that. I am expecting some answers...

Best, -Michael

On Wed, 2016-01-13 at 15:51 +0100, Daniel Weismüller wrote:

Hi Marcel

And a happy new year. ;-)

I'm a bit sad about that I didn't get an answer from you. A few minutes ago I've taken a look to your git and notices that you have removed the new-apache-php branch.

I know it would be bit work to do to separate every part of your existing work into their own branches but I really tried to explain you the requirement.

Finally I hope that you are still interested to share your work with the project?

yours Daniel

Am 21.12.2015 um 15:43 schrieb Daniel Weismüller:

...

Hi Marcel

Sorry for the late answer.

I've taken a look on your new branch.

I'm really saddened to have to say that we still can't use it.

We can't use update packs like you build them. We need every single thing in his own branch. I know it is much more effort but at least it is much better because they won't collide with other updates. Another advantage is that each part is individually maintainable.

So it would be really great if you could split your work into cutie little pieces. :-)

Thanks a lot.

• Daniel

Am 04.12.2015 um 19:22 schrieb Marcel Lorenz:

...

Hi Daniel

I have created a test branch new-apache-php. With berekeley 6.1.26 and ICU 56.1 for apache. mcrypt is a prerequisite for php.

Apache ./configure log :

checking db6/db.h usability... yes checking db6/db.h presence... yes checking for db6/db.h... yes checking for -ldb-6.1... yes checking for Berkeley DB... found db6 checking for default DBM... sdbm (default) setting LDADD_dbm_db to "-ldb-6.1"

Commit text: Update to new Apache 2.4 and PHP 5.6

Apache 2.4.17 PHP 5.6.16 mcrypt 2.6.8 (new)

Comments: Apache works in event mode and uses Berkeley DB6 PHP is multithreaded

Apache config folder is changed from /etc/httpd/conf/ to /etc/httpd/ Apache 2.4.x need this change. The sysconfdir layout entry has no effekt more. All relevant lfs and rootfiles are updated (owncloud, naigos(sql), phpSANE, icniga, cacti)

http://git.ipfire.org/?p=people/mlorenz/ipfire-2.x.git;a=shortlog ;h=refs/heads/new-apache-php

I have testet the iso from this branch. Owncloud, cacti , icniga, naigos has yet to be tested..

Marcel

Hi all, to leave a fast insight of my approach in developing some new ideas or features for IPFire, i tried normally to find people who are interested in a specific feature which i found useful, so if there were some responses i tried to go in a kind of testing scenario where the community could also brought on new ideas, own development, possible bugs or problems but also to collect material and ideas or possible extensions for a documentation in the wiki. This procedure brought in the past some usable results in my opinion where it was possible with relatively few bugs, a more detailed documentation and some more people from the community which are earlier integrated in such projects to deliver a better result to IPFire where it could finally be reviewed. This process do not work always in a straight way or brings sometimes to many problems up where the second view figures too much problems out and the project stucks or comes to an unforeseeable end which is sometimes a pity cause of the invested work but may better in some cases.

Regarding to the Mailproxy/Mailserver project i tried to help interested people out as far as i could to support also similar intends but also to find with more people ways to be maintainers for some very old and outdated IPFire Addons. Postfix is a kind of big regarding to the update scenario cause a lot of basic components are involved in that process (Perl, PHP, Apache, Amavisd, Spamassassin, BerkeleyDB to name a few). Just to make it a little more understandable what happens in this project specifically, there was and i think is the willingness to develop a working environment where all updated packages comes together for testings before a merge request but also a proper configuration are in place to went through different testing environments and get also a better/deeper insight and feedback if things are working and if not, how could it be made better. As time goes by, a lot of updates has been done in that topic and the current state there is a kind of stable i think. In my point of view there is the need that possible maintainers of the, let´s say, mail project find together with the core developer a structure how to deliver all that in smaller steps which are useful and good for the IPFire project.

So from my side, i can imagine to support this process further if there is the will for cooperation on both sides and ideas how we can proceed with this. I think also that it is very important that possible maintainers of such projects are present also in this environment (developer mailinglist) to find together a efficient progress of development.

Some thoughts from my side.

Greetings,

Erik

Am 19.01.2016 um 09:41 schrieb Dirk Reitz dirk.reitz@gmail.com:

Dear Michael and all other developers,

I am sorry to realize at least some frustration out of your post.

This has never been our intention and still is not. Although we got some hints/informations regarding the developer mailing list, we thought it would be enough to show our projects and progress in the developer part of the forum - obviously wrong, our fault ! Our intention was to expand the functionality of ipfire as a central part of the network - therefore we started the development of our projects. In addition we wanted to help future development of ipfire - we hoped that some of our work could be reused, but we never expected anything from you Michael or other developers.

As Marcel is not so familiar writing in english, I offered to do this instead (for the mail proxy/mail server).

I agree that our projects have diverted a lot from ipfire, but I am confident we are able to sort it out. Please let me know, what I can/should do

best regards Dirk

...

Am 19.01.2016 um 02:16 schrieb Michael Tremer michael.tremer@ipfire.org:

Hello,

I am actually at a point now where I think we need to talk about this. A lot.

So many people have been starting to contribute to this project - or as I sometimes see it - to parallel projects. Projects that are developed in parallel to the main distribution. Projects that have different goals or are at least from my perspective heading into a different direction.

The mail proxy/mail server/web mail project is one like these. There are also others like multiple versions of the update accelerator and some more.

These changes are never submitted on here. There is not even a conversation on here about that being a goal. Despite me having multiple chats with people about how this process works and that they want to do it, soon-ish.

So here we are. Months later. With no progress at all.

Instead I am getting requests and bug reports for that software that I am not involved with at all. People tell me that bugs are fixed there or that there are features available they want to use. They ask when this will be available in the distribution.

I don't have an answer to that. And what is even worse is that right now I am too tired to look into this.

These projects have diverted a lot in that sense that an easy merge is no longer possible. It will take a lot of work to split up the changes, test them, confirm that they work, do QA and then release them. This process itself is not foolproof and we are not getting a lot of feedback. We just get the backlash when something is not working properly. It will be very tough.

Working on these changes step by step would have certainly avoided getting to this state. Now we are at it. Frankly, I do not know what to do.

I will certainly not sit down and take these things apart myself. I have actually not much interest in working on these things any way. Cleaning up after somebody else won't be my main job for the next few weeks. That is partly because I don't want to and partly because that won't work any way. It is not my code.

The other option would be just to leave these projects as they are. That may either be getting old and rot in a git tree. That may either be them becoming something else. But I do not think that any of these is the best option for the IPFire project as a whole. I am very much interested in keeping that as the main target of my work.

And that might me or other IPFire developers to do the same work again. In this specific example update apache. From my point of view that only wasted valuable developer time. In both projects. That can't be the ideal.

So I would like to hear that from the people who are working on these parallel projects what they are intending to do and what they are expecting from me/the other developers. I honestly do not know if you think yourself that this is an issue, too. So let's have a productive discussion about that. I am expecting some answers...

Best, -Michael

On Wed, 2016-01-13 at 15:51 +0100, Daniel Weismüller wrote:

...

Hi Marcel

And a happy new year. ;-)

I'm a bit sad about that I didn't get an answer from you. A few minutes ago I've taken a look to your git and notices that you have removed the new-apache-php branch.

I know it would be bit work to do to separate every part of your existing work into their own branches but I really tried to explain you the requirement.

Finally I hope that you are still interested to share your work with the project?

yours Daniel

Am 21.12.2015 um 15:43 schrieb Daniel Weismüller:

...

Hi Marcel

Sorry for the late answer.

I've taken a look on your new branch.

I'm really saddened to have to say that we still can't use it.

We can't use update packs like you build them. We need every single thing in his own branch. I know it is much more effort but at least it is much better because they won't collide with other updates. Another advantage is that each part is individually maintainable.

So it would be really great if you could split your work into cutie little pieces. :-)

Thanks a lot.

• Daniel

Am 04.12.2015 um 19:22 schrieb Marcel Lorenz:

...

Hi Daniel

I have created a test branch new-apache-php. With berekeley 6.1.26 and ICU 56.1 for apache. mcrypt is a prerequisite for php.

Apache ./configure log :

checking db6/db.h usability... yes checking db6/db.h presence... yes checking for db6/db.h... yes checking for -ldb-6.1... yes checking for Berkeley DB... found db6 checking for default DBM... sdbm (default) setting LDADD_dbm_db to "-ldb-6.1"

Commit text: Update to new Apache 2.4 and PHP 5.6

Apache 2.4.17 PHP 5.6.16 mcrypt 2.6.8 (new)

Comments: Apache works in event mode and uses Berkeley DB6 PHP is multithreaded

Apache config folder is changed from /etc/httpd/conf/ to /etc/httpd/ Apache 2.4.x need this change. The sysconfdir layout entry has no effekt more. All relevant lfs and rootfiles are updated (owncloud, naigos(sql), phpSANE, icniga, cacti)

http://git.ipfire.org/?p=people/mlorenz/ipfire-2.x.git;a=shortlog ;h=refs/heads/new-apache-php

I have testet the iso from this branch. Owncloud, cacti , icniga, naigos has yet to be tested..

Marcel

Hi all,

Am 19.01.2016 um 12:41 schrieb Michael Tremer michael.tremer@ipfire.org:

When starting with something we often don't know where we will end up. That's quite normal. However going to the very end won't work either.

That´s true but i´am not sure what you mean with "going to the very end" ? Regarding to the mailproxy/server project it is beneath an also surely commercial intend also a kind of fun for the involved people there to build up some features they want to have but it contains also a little knowledge (may for other interested people) of how it is possible to build your own stuff in a Linux from Scratch environment by examples and realize your own wishes but also concrete steps how it could be in general possible to deliver bugs or to handle a little more with Git and i know about the will of the involved people to cooperate with the IPFire project and deliver their work too but there are sadly some obstacles sometimes with language (english in this case) and possibly also the how to integrate themselves into the development process. I´am not sure how much + work you have had causing this project but basically this circle (3-5 people) tried to help themselves at all and not to stick to the core developers and their time, also a bigger part of the work which was done in there concerns also the core part of IPFire. May it is the wrong part to discuss the sense of Addons like Postfix, Amavisd or even Spamassassin on IPFire since they where and are available, some people are interested in the usage of it and the project starts initially with an idea to implement another security layer like the mailproxy. This aren´t a core part of IPFire since you need to install this Addons first, it can be seen a little similar to the Copfilter project. Nevertheless i do not see updates for Apache, PHP, Perl and a lot of other basic (common) components as a beside work or 3rd party stuff please correct me if i´am wrong.

The whole Email flood you deliver may cause also of this kind of projects which are going on in the forum but how should we deal with this ? The forum is a good possibility to find a wider range of people with various systems, i think it is also a voice from and for the community beneath small talk and support. It is hard to see before what will happens with this or that topic or how much questions will be addressed to the wrong people. Could it be a solution to redirect them just to the appropriate topics if you have nothing to do with this code ?

We can't ship that all in just one update. There are many reasons for that.

1. The updates will get too big to ship.

2. The updates will be too big to get tested. Not many people are

engaging in this any way.

And we actually don't need to have this so stressful.

Some things of that like PHP can be updated individually or with fewer dependencies. So we start with that and go on from there.

For sure. I tried to deliver this many time also in other forum sections, in that specific i tried to deliver ideas of how we can split all that into bite-sized morsels, mentioned also many times the usage of the mailinglist and have called for the usage of it and i don´t know why it is such a big hurdle even a lot of stuff are already available. Although some help also in there is definitely needed cause we stuck there also with some unsolvable problems. PHP and Apache was also a splitted working part of that and i currently do not know what the state or problem is in there ?

Does anyone know if they are even all subscribed?

Not sure about that, have seen Dirk so far, Daniel has delivered the mail correspondence with Marcel in here, Thomas wrote also in here some time ago i think and Matthias helped in the forums section also out and is shurley also here present ;-).

So let me mentioned in the end. Like Dirk said it already, it was and is not our intend to make things worst with our Forum projects for anybody, the opposite was the case and i feel a little sorry that all the achieved work produces frustration cause it was also meant to save time for the core developers by delivering tested updates also for core system components where it sadly seems to struggles at the end by finding a solution how to deliver them or simply to speak with another. For myself, i have also some other open projects in the forum (e.g. Portspoof, Pmacct, Ossec) which may also never comes to an end simply because it is nice to research for new functionalities also with other people but also to bring on new ideas and cast an eye on new stuff. I can understand the hassle which you have Michael, so just say it and i will close them and stop this kind of work if it makes no sense at all but only stress.

So far from here.

Greetings,

Erik

Hello,

thank you for your comment.

I pretty much agree despite that I am not the only maintainer of IPFire 2 and IPFire 3. We should move on to IPFire 3 as soon as possible so that we can use the benefits of the build system and the social development process we have built there.

Best, -Michael

On Wed, 2016-01-20 at 13:04 +0100, Jonatan Schlag wrote:

Hi all,

I am a user of IPFire, but i also develop ( in the moment for me alone), things which i need. It is no easy to follow this conversation, so if do not cover anything I just do this because the discussion is to big o comment it at once and I think this is not necessary. In the moment I see Michael Tremer, which is Maintainer of the “whole” project. And I see a lot of other people here and in the forum which contribute, and want to contribute. That the people want to contribute is simple great. The problem is from my point of view the way how they do that and how the whole project “work!” in the moment. Please do not misunderstand me, the last thing what I want is to say this is your or you fault. I know enough situation where people do that and make only noise, but do not solve any Problems. So I do not think that these parallel projects should be separated, this only split the energy, and this is not good. What I think is that I should be clear who is appropriate for this or for these. Michael is not appropriate for maintain every thing and write thousand of E – Mails. He is appropriate for the core. When people development a addon they should maintain it. I know that IPFire a firewall router is but some addons may be useful. Not for everyone but for some people they are useful. So they could be developed, but should not be maintained by the core developers. The core developers should maintain the core and nothing else. So maybe is is a solution to drop every addon which has no maintainer (this is a very hard way). But for this we need a information in the lfs files like in IPFire 3 # maintainer = Jonatan Schlag (jonatan(at)familyschlag.de) So it is more clear which person is appropriate for which thing.

So this are some thoughts form my side. I hope they are useful.

Yours Sincerely Jonatan Schlag

Hi,

thanks for the responses so far.

On 19/01/2016 08:41 AM, Dirk Reitz wrote:

Dear Michael and all other developers,

I am sorry to realize at least some frustration out of your post.

I am indeed a little bit frustrated, but this is not what this emails are about. I will get over it.

This has never been our intention and still is not. Although we got some hints/informations regarding the developer mailing list, we thought it would be enough to show our projects and progress in the developer part of the forum - obviously wrong, our fault !

It also not about finding out who's fault something is. This is about making IPFire better. And when people are working on making things better that should be integrated into the distribution.

Our intention was to expand the functionality of ipfire as a central part of the network - therefore we started the development of our projects. In addition we wanted to help future development of ipfire - we hoped that some of our work could be reused, but we never expected anything from you Michael or other developers.

Well, for this being used it has to be submitted as patches. In small and reviewable and testable chunks.

As Marcel is not so familiar writing in english, I offered to do this instead (for the mail proxy/mail server).

I agree that our projects have diverted a lot from ipfire, but I am confident we are able to sort it out.

How?

Please let me know, what I can/should do

Keep this conversation running is the only thing I am asking for. We will figure out the rest from here...

best regards Dirk

-Michael

...

Am 19.01.2016 um 02:16 schrieb Michael Tremer michael.tremer@ipfire.org:

Hello,

I am actually at a point now where I think we need to talk about this. A lot.

So many people have been starting to contribute to this project - or as I sometimes see it - to parallel projects. Projects that are developed in parallel to the main distribution. Projects that have different goals or are at least from my perspective heading into a different direction.

The mail proxy/mail server/web mail project is one like these. There are also others like multiple versions of the update accelerator and some more.

These changes are never submitted on here. There is not even a conversation on here about that being a goal. Despite me having multiple chats with people about how this process works and that they want to do it, soon-ish.

So here we are. Months later. With no progress at all.

Instead I am getting requests and bug reports for that software that I am not involved with at all. People tell me that bugs are fixed there or that there are features available they want to use. They ask when this will be available in the distribution.

I don't have an answer to that. And what is even worse is that right now I am too tired to look into this.

These projects have diverted a lot in that sense that an easy merge is no longer possible. It will take a lot of work to split up the changes, test them, confirm that they work, do QA and then release them. This process itself is not foolproof and we are not getting a lot of feedback. We just get the backlash when something is not working properly. It will be very tough.

Working on these changes step by step would have certainly avoided getting to this state. Now we are at it. Frankly, I do not know what to do.

I will certainly not sit down and take these things apart myself. I have actually not much interest in working on these things any way. Cleaning up after somebody else won't be my main job for the next few weeks. That is partly because I don't want to and partly because that won't work any way. It is not my code.

The other option would be just to leave these projects as they are. That may either be getting old and rot in a git tree. That may either be them becoming something else. But I do not think that any of these is the best option for the IPFire project as a whole. I am very much interested in keeping that as the main target of my work.

And that might me or other IPFire developers to do the same work again. In this specific example update apache. From my point of view that only wasted valuable developer time. In both projects. That can't be the ideal.

So I would like to hear that from the people who are working on these parallel projects what they are intending to do and what they are expecting from me/the other developers. I honestly do not know if you think yourself that this is an issue, too. So let's have a productive discussion about that. I am expecting some answers...

Best, -Michael

On Wed, 2016-01-13 at 15:51 +0100, Daniel Weismüller wrote: Hi Marcel

And a happy new year. ;-)

I'm a bit sad about that I didn't get an answer from you. A few minutes ago I've taken a look to your git and notices that you have removed the new-apache-php branch.

I know it would be bit work to do to separate every part of your existing work into their own branches but I really tried to explain you the requirement.

Finally I hope that you are still interested to share your work with the project?

yours Daniel

Am 21.12.2015 um 15:43 schrieb Daniel Weismüller: Hi Marcel

Sorry for the late answer.

I've taken a look on your new branch.

I'm really saddened to have to say that we still can't use it.

We can't use update packs like you build them. We need every single thing in his own branch. I know it is much more effort but at least it is much better because they won't collide with other updates. Another advantage is that each part is individually maintainable.

So it would be really great if you could split your work into cutie little pieces. :-)

Thanks a lot.

• Daniel

Am 04.12.2015 um 19:22 schrieb Marcel Lorenz: Hi Daniel

I have created a test branch new-apache-php. With berekeley 6.1.26 and ICU 56.1 for apache. mcrypt is a prerequisite for php.

Apache ./configure log :

checking db6/db.h usability... yes checking db6/db.h presence... yes checking for db6/db.h... yes checking for -ldb-6.1... yes checking for Berkeley DB... found db6 checking for default DBM... sdbm (default) setting LDADD_dbm_db to "-ldb-6.1"

Commit text: Update to new Apache 2.4 and PHP 5.6

Apache 2.4.17 PHP 5.6.16 mcrypt 2.6.8 (new)

Comments: Apache works in event mode and uses Berkeley DB6 PHP is multithreaded

Apache config folder is changed from /etc/httpd/conf/ to /etc/httpd/ Apache 2.4.x need this change. The sysconfdir layout entry has no effekt more. All relevant lfs and rootfiles are updated (owncloud, naigos(sql), phpSANE, icniga, cacti)

http://git.ipfire.org/?p=people/mlorenz/ipfire-2.x.git;a=shortlog ;h=refs/heads/new-apache-php

I have testet the iso from this branch. Owncloud, cacti , icniga, naigos has yet to be tested..

Marcel

Ok, just adding my opinion.

I agree that IPFire is, for me, a firewall/vpn/router. I really have very little use for anything else. I like (and have used) the Tor addon, and I have used Cacti installed on it also, but really, the lack of any of these would NOT impact my use of IPFire. I install Samba simply so I can get old Windows name resolution (NOT for file storage), but again, the lack of that would not impact me.

My personal opinion is that the core developers work on things which make IPFire a better firewall/vpn/router (yes, I use the hell out of VPN), and everything else is fluff. Asterisk? Really? flac and alsa? nagios/cacti? Owncloud (I use it, but it is on a separate server and I'd never think of putting it on a router). sane? "My router can scan better than your desktop!!!" And transmission is on my desktop, not even my server.

Currently there is a problem with dnsmasq, and Matthias is going crazy trying to figure it out (I think there will be a time when he dreads any bug reports from me, and that time may have passed). Michael has been talking less and less about the new version of IPFire in the works, and I can only guess it is because he spends so much time supporting non-core functions.

I don't know if it is feasible, but could a secondary repository of non-firewall related projects be set up and NOT supported by the core developers. There are very few core developers, and losing their interest to non-firewall related projects is, and will continue to hurt the project. Anything in the secondary repository would be clearly labeled "These 3rd party applications are not supported by the core development team."

Hell, for that matter, I eat, breath and sleep with the editor joe, and was very happy to see it included in the available modules. But, if joe wasn't available, I'd use vim (YUK).

Don't kill the enthusiasm of people developing the non-firewall related modules, but definitely separate them out. Maybe even a separate mailing list. But before anything is added to the core project, ask the question "does it enhance IPFire as a vpn/firewall/router" and if the answer is no, then don't include or support it. Let the third party developers do that.

Let the few core developers we have get back to making IPFire the great project it is.

Rod

On 01/19/2016 02:56 PM, David J. Allen wrote:

While I am only a user, I am on this list so I can keep up with the progress and tone of the project. One can tell a lot about the health of the developer community involved in a project and thus the health of, and likely future of the project itself (e.g. likely to improve, getting stale, dying).

So my comments should be taken in that context: one user's perspective.

On 01/18/2016 05:16 PM, Michael Tremer wrote:

...

Hello,

I am actually at a point now where I think we need to talk about this. A lot.

So many people have been starting to contribute to this project - or as I sometimes see it - to parallel projects. Projects that are developed in parallel to the main distribution. Projects that have different goals or are at least from my perspective heading into a different direction.

The mail proxy/mail server/web mail project is one like these. There are also others like multiple versions of the update accelerator and some more.

I use IPfire intentionally and *only* because it is a router/firewall, and a good one. I am /not/ interested in it as an alternative Linux distribution, or as web server, development platform, DNS server, printer server, graphics workstation, or gaming zone.

It's my router. Period. I don't need or want other non-router, non-firewall crap added to the recipe. If I wanted a Swiss Army knife distribution, there are plenty of others to look at*.

"Do one thing, and do it well".

*I'm already not happy that IPfire has followed the herd into Systemd-land, since that path will lead (has lead) to more bugs and (hidden) security holes, as there are virtually no reliable security audits or real testing done by the ignorant "Change-for-change's-sake hipsters developing Systemd. However I can understand why you have gone that way, given that you depend on upstream code for most of your core systems, and it is now pretty much impossible to remove systemd's tendrils from even userland code ("One ring to bind them all").

And now that pretty much every Linux distro is defacto a Redhat/Fedora distro, you have no choice.

...

These changes are never submitted on here. There is not even a conversation on here about that being a goal. Despite me having multiple chats with people about how this process works and that they want to do it, soon-ish.

So here we are. Months later. With no progress at all.

So, then just ignore these "parallel" projects. They may be parallel in that they use IPfire as their code base, but they are, in my opinion, *not* Ipfire and should not claim to be.

...

Instead I am getting requests and bug reports for that software that I am not involved with at all. People tell me that bugs are fixed there or that there are features available they want to use. They ask when this will be available in the distribution.

I don't have an answer to that. And what is even worse is that right now I am too tired to look into this.

Again. I suggest you just ignore those requests in as tactful manner as possible. Tell them to talk to the hand.

Why should you be responsible for someone's fork of /your/ project? Do you feel obligated to answer questions about any other distro (and Ipfire really /is/ a Linux distribution)?

...

These projects have diverted a lot in that sense that an easy merge is no longer possible. It will take a lot of work to split up the changes, test them, confirm that they work, do QA and then release them. This process itself is not foolproof and we are not getting a lot of feedback. We just get the backlash when something is not working properly. It will be very tough.

Very tough *and* very unnecessary. Don't do that work. If if diverts your attention from Ipfire-the-router, then eventually if will negatively affect the quality of your code, and robustness of Ipfire. The last thing I want to use is a poorly built router/firewall.

...

Working on these changes step by step would have certainly avoided getting to this state. Now we are at it. Frankly, I do not know what to do.

Such work would still have served no legitimate purpose in the context of a secure software router.

What to do? Easy. Get back to your roots or risk losing users.

...

I will certainly not sit down and take these things apart myself. I have actually not much interest in working on these things any way. Cleaning up after somebody else won't be my main job for the next few weeks. That is partly because I don't want to and partly because that won't work any way. It is not my code.

There. You've said. That's all the reason you need right there. No need to apologize or wring hands over that kind of honesty.

...

The other option would be just to leave these projects as they are. That may either be getting old and rot in a git tree. That may either be them becoming something else. But I do not think that any of these is the best option for the IPFire project as a whole. I am very much interested in keeping that as the main target of my work.

How about just kick non-router/firewall-related projects to the curb.

Tell those who wish to add non-Ipfire cruft to go start their own distributions, set up their own servers, support teams, build up their own user community, and distribution, marketing, infrastructure, and all the other shit it takes, on their own dime.

...

And that might me or other IPFire developers to do the same work again. In this specific example update apache. From my point of view that only wasted valuable developer time. In both projects. That can't be the ideal.

So I would like to hear that from the people who are working on these parallel projects what they are intending to do and what they are expecting from me/the other developers. I honestly do not know if you think yourself that this is an issue, too. So let's have a productive discussion about that. I am expecting some answers...

Best, -Michael

You seem to have made what sounds like a disclaimer of your responsibility for what amounts to non-Ipfire (the concept) code. Why stop at halfway. Just do it:

Tell us "IpFire is a software router and firewall. That's it. It hopes to be the best in class at what it's intended to be. Nothing less. If you want something other than a world-class router and firewall, go somewhere else. If you want to help us in /our/ goal, then welcome aboard."

I can tell you that as a user, I know what *I* want from a router-firewall. I want rock solid security. I want robustness. I want a reasonably small footprint. I want the best possible performance. I want maintainability. I want it to just run and do the job it is designed to do. Nothing less, and certainly *nothing more*.

If I can't get that from IPfire, I'll go somewhere else. You have some good competition. In light of recent events in the Linux world *cough*cough*systemd* you're already at risk of losing users to similar BSD-based utilities.

And I still have an expensive, and very good appliance router-firewall sitting on the shelf which is not very happy about being replaced by IPfire. ;)

Just my opinion as a user.

Best Regards, David.

[snip]

Hi,

On Tue, 2016-01-19 at 15:59 -0600, R. W. Rodolico wrote:

Ok, just adding my opinion.

I agree that IPFire is, for me, a firewall/vpn/router. I really have very little use for anything else. I like (and have used) the Tor addon, and I have used Cacti installed on it also, but really, the lack of any of these would NOT impact my use of IPFire. I install Samba simply so I can get old Windows name resolution (NOT for file storage), but again, the lack of that would not impact me.

My personal opinion is that the core developers work on things which make IPFire a better firewall/vpn/router (yes, I use the hell out of VPN), and everything else is fluff. Asterisk? Really? flac and alsa? nagios/cacti? Owncloud (I use it, but it is on a separate server and I'd never think of putting it on a router). sane? "My router can scan better than your desktop!!!" And transmission is on my desktop, not even my server.

Well, many of these things have been removed from the distribution. There didn't be to seem any interest in them and we couldn't detect any users.

Currently there is a problem with dnsmasq, and Matthias is going crazy trying to figure it out (I think there will be a time when he dreads any bug reports from me, and that time may have passed). Michael has been talking less and less about the new version of IPFire in the works, and I can only guess it is because he spends so much time supporting non -core functions.

I don't want to get into the dnsmasq thing. That is something else.

However I would like to explain a little to where my time goes. Just so that you can get an impression. It is actually not a lot that goes into supporting anything. Most of the time is wasted on admin. I am in touch with people who are doing various stuff around the project. I have been investing a lot into our rotting infrastructure. I have been trying to set up a marketing team. I am constantly busy with trying to motivate people. I am doing taxes. I am trying to find sponsors. I am replying or deleting senseless emails where people could have just googled. I am relying information from one group of people to an other group of people because nobody can either communicate directly or use the fucking mailing list. I have been trying to establish a productive developer summit and other exhibitions the project could attend. I am trying to keep the bugtracker updated and triage bugs. I remind people about their bugs and other promises they made.

Then there is my day job.

So at the very end of a day I maybe have like 15 minutes left to do development work. That is nothing at all. It is nothing that will get this project to move anywhere.

So that is why I have decided to just cut off some things and not invest too much time there any more. Like the developer summit. At that point where you don't see any outcome what so ever from that there is no point in doing it any more. That is just wasted money and wasted time for me. Let's see what else there will be in the future just to get rid of.

I hope that this will be a way to find me some more time to do development work because that is actually what I would like to do.

I don't know if it is feasible, but could a secondary repository of non-firewall related projects be set up and NOT supported by the core developers. There are very few core developers, and losing their interest to non-firewall related projects is, and will continue to hurt the project. Anything in the secondary repository would be clearly labeled "These 3rd party applications are not supported by the core development team."

We are trying to establish something like that with IPFire 3.

Many people have applications set up on top of IPFire. These are usually companies who make money from that and do not give back anything whatsoever.

Hell, for that matter, I eat, breath and sleep with the editor joe, and was very happy to see it included in the available modules. But, if joe wasn't available, I'd use vim (YUK).

I don't think that having joe in there is loads of trouble. You can maintain that package yourself and send patches when ever needed. That is how I imagine development to be working in the future if we can get to that.

Don't kill the enthusiasm of people developing the non-firewall related modules, but definitely separate them out. Maybe even a separate mailing list.

We do have various lists for that. Mainly they use the forums any way. So they do that automatically. I find this is exactly the issue that I want to talk about here. Is that a good idea to single them out?

But before anything is added to the core project, ask the question "does it enhance IPFire as a vpn/firewall/router" and if the answer is no, then don't include or support it. Let the third party developers do that.

Let the few core developers we have get back to making IPFire the great project it is.

Get back?! oO

-Michael

Rod

On 01/19/2016 02:56 PM, David J. Allen wrote:

...

While I am only a user, I am on this list so I can keep up with the progress and tone of the project. One can tell a lot about the health of the developer community involved in a project and thus the health of, and likely future of the project itself (e.g. likely to improve, getting stale, dying).

So my comments should be taken in that context: one user's perspective.

On 01/18/2016 05:16 PM, Michael Tremer wrote:

...

Hello,

I am actually at a point now where I think we need to talk about this. A lot.

So many people have been starting to contribute to this project - or as I sometimes see it - to parallel projects. Projects that are developed in parallel to the main distribution. Projects that have different goals or are at least from my perspective heading into a different direction.

The mail proxy/mail server/web mail project is one like these. There are also others like multiple versions of the update accelerator and some more.

I use IPfire intentionally and *only* because it is a router/firewall, and a good one. I am /not/ interested in it as an alternative Linux distribution, or as web server, development platform, DNS server, printer server, graphics workstation, or gaming zone.

It's my router. Period. I don't need or want other non-router, non-firewall crap added to the recipe. If I wanted a Swiss Army knife distribution, there are plenty of others to look at*.

"Do one thing, and do it well".

*I'm already not happy that IPfire has followed the herd into Systemd-land, since that path will lead (has lead) to more bugs and (hidden) security holes, as there are virtually no reliable security audits or real testing done by the ignorant "Change-for-change's -sake hipsters developing Systemd. However I can understand why you have gone that way, given that you depend on upstream code for most of your core systems, and it is now pretty much impossible to remove systemd's tendrils from even userland code ("One ring to bind them all").

And now that pretty much every Linux distro is defacto a Redhat/Fedora distro, you have no choice.

...

These changes are never submitted on here. There is not even a conversation on here about that being a goal. Despite me having multiple chats with people about how this process works and that they want to do it, soon-ish.

So here we are. Months later. With no progress at all.

So, then just ignore these "parallel" projects. They may be parallel in that they use IPfire as their code base, but they are, in my opinion, *not* Ipfire and should not claim to be.

...

Instead I am getting requests and bug reports for that software that I am not involved with at all. People tell me that bugs are fixed there or that there are features available they want to use. They ask when this will be available in the distribution.

I don't have an answer to that. And what is even worse is that right now I am too tired to look into this.

Again. I suggest you just ignore those requests in as tactful manner as possible. Tell them to talk to the hand.

Why should you be responsible for someone's fork of /your/ project? Do you feel obligated to answer questions about any other distro (and Ipfire really /is/ a Linux distribution)?

...

These projects have diverted a lot in that sense that an easy merge is no longer possible. It will take a lot of work to split up the changes, test them, confirm that they work, do QA and then release them. This process itself is not foolproof and we are not getting a lot of feedback. We just get the backlash when something is not working properly. It will be very tough.

Very tough *and* very unnecessary. Don't do that work. If if diverts your attention from Ipfire-the-router, then eventually if will negatively affect the quality of your code, and robustness of Ipfire. The last thing I want to use is a poorly built router/firewall.

...

Working on these changes step by step would have certainly avoided getting to this state. Now we are at it. Frankly, I do not know what to do.

Such work would still have served no legitimate purpose in the context of a secure software router.

What to do? Easy. Get back to your roots or risk losing users.

...

I will certainly not sit down and take these things apart myself. I have actually not much interest in working on these things any way. Cleaning up after somebody else won't be my main job for the next few weeks. That is partly because I don't want to and partly because that won't work any way. It is not my code.

There. You've said. That's all the reason you need right there. No need to apologize or wring hands over that kind of honesty.

...

The other option would be just to leave these projects as they are. That may either be getting old and rot in a git tree. That may either be them becoming something else. But I do not think that any of these is the best option for the IPFire project as a whole. I am very much interested in keeping that as the main target of my work.

How about just kick non-router/firewall-related projects to the curb.

Tell those who wish to add non-Ipfire cruft to go start their own distributions, set up their own servers, support teams, build up their own user community, and distribution, marketing, infrastructure, and all the other shit it takes, on their own dime.

...

And that might me or other IPFire developers to do the same work again. In this specific example update apache. From my point of view that only wasted valuable developer time. In both projects. That can't be the ideal.

So I would like to hear that from the people who are working on these parallel projects what they are intending to do and what they are expecting from me/the other developers. I honestly do not know if you think yourself that this is an issue, too. So let's have a productive discussion about that. I am expecting some answers...

Best, -Michael

You seem to have made what sounds like a disclaimer of your responsibility for what amounts to non-Ipfire (the concept) code. Why stop at halfway. Just do it:

Tell us "IpFire is a software router and firewall. That's it. It hopes to be the best in class at what it's intended to be. Nothing less. If you want something other than a world-class router and firewall, go somewhere else. If you want to help us in /our/ goal, then welcome aboard."

I can tell you that as a user, I know what *I* want from a router-firewall. I want rock solid security. I want robustness. I want a reasonably small footprint. I want the best possible performance. I want maintainability. I want it to just run and do the job it is designed to do. Nothing less, and certainly *nothing more*.

If I can't get that from IPfire, I'll go somewhere else. You have some good competition. In light of recent events in the Linux world *cough*cough*systemd* you're already at risk of losing users to similar BSD-based utilities.

And I still have an expensive, and very good appliance router -firewall sitting on the shelf which is not very happy about being replaced by IPfire. ;)

Just my opinion as a user.

Best Regards, David.

[snip]

Hi,

On Tue, 2016-01-19 at 19:02 -0600, R. W. Rodolico wrote:

On 01/19/2016 05:25 PM, Michael Tremer wrote:

...

Hi,

On Tue, 2016-01-19 at 15:59 -0600, R. W. Rodolico wrote:

...

Ok, just adding my opinion.

I agree that IPFire is, for me, a firewall/vpn/router. I really have very little use for anything else. I like (and have used) the Tor addon, and I have used Cacti installed on it also, but really, the lack of any of these would NOT impact my use of IPFire. I install Samba simply so I can get old Windows name resolution (NOT for file storage), but again, the lack of that would not impact me.

My personal opinion is that the core developers work on things which make IPFire a better firewall/vpn/router (yes, I use the hell out of VPN), and everything else is fluff. Asterisk? Really? flac and alsa? nagios/cacti? Owncloud (I use it, but it is on a separate server and I'd never think of putting it on a router). sane? "My router can scan better than your desktop!!!" And transmission is on my desktop, not even my server.

Well, many of these things have been removed from the distribution. There didn't be to seem any interest in them and we couldn't detect any users.

...

Currently there is a problem with dnsmasq, and Matthias is going crazy trying to figure it out (I think there will be a time when he dreads any bug reports from me, and that time may have passed). Michael has been talking less and less about the new version of IPFire in the works, and I can only guess it is because he spends so much time supporting non -core functions.

I don't want to get into the dnsmasq thing. That is something else.

Sorry, just meant it as an example of something which affects the base use of IPFire.

This is indeed an issue. I just didn't want to deviate from topic here. Let's talk about that in the other thread.

...

However I would like to explain a little to where my time goes. Just so that you can get an impression. It is actually not a lot that goes into supporting anything. Most of the time is wasted on admin. I am in touch with people who are doing various stuff around the project. I have been investing a lot into our rotting infrastructure. I have been trying to set up a marketing team. I am constantly busy with trying to motivate people. I am doing taxes. I am trying to find sponsors. I am replying or deleting senseless emails where people could have just googled. I am relying information from one group of people to an other group of people because nobody can either communicate directly or use the fucking mailing list. I have been trying to establish a productive developer summit and other exhibitions the project could attend. I am trying to keep the bugtracker updated and triage bugs. I remind people about their bugs and other promises they made.

Then there is my day job.

You have a day job?

Yes, because the IPFire project does not pay me any money. I am getting some jobs because of my work in and around IPFire, but pretty much 99% of the development work is not being paid for.

So to be able to pay rent and buy food and so on I need to do other things.

...

So at the very end of a day I maybe have like 15 minutes left to do development work. That is nothing at all. It is nothing that will get this project to move anywhere.

So that is why I have decided to just cut off some things and not invest too much time there any more. Like the developer summit. At that point where you don't see any outcome what so ever from that there is no point in doing it any more. That is just wasted money and wasted time for me. Let's see what else there will be in the future just to get rid of.

I hope that this will be a way to find me some more time to do development work because that is actually what I would like to do.

+1 for that idea

...

...

I don't know if it is feasible, but could a secondary repository of non-firewall related projects be set up and NOT supported by the core developers. There are very few core developers, and losing their interest to non-firewall related projects is, and will continue to hurt the project. Anything in the secondary repository would be clearly labeled "These 3rd party applications are not supported by the core development team."

We are trying to establish something like that with IPFire 3.

Many people have applications set up on top of IPFire. These are usually companies who make money from that and do not give back anything whatsoever.

...

Hell, for that matter, I eat, breath and sleep with the editor joe, and was very happy to see it included in the available modules. But, if joe wasn't available, I'd use vim (YUK).

I don't think that having joe in there is loads of trouble. You can maintain that package yourself and send patches when ever needed. That is how I imagine development to be working in the future if we can get to that.

That is my point. If I want joe, then it is my job to take the time to include it. For me, I'd just use vim if it came to that. I'm happy it is there, and I'm not downgrading it at all, again, it was just an example of something that does not enhance the firewall itself. But, I've very, very happy it is there.

...

...

Don't kill the enthusiasm of people developing the non-firewall related modules, but definitely separate them out. Maybe even a separate mailing list.

We do have various lists for that. Mainly they use the forums any way. So they do that automatically. I find this is exactly the issue that I want to talk about here. Is that a good idea to single them out?

Personally, I think so. Nothing to degrade their work. I think it is great. But anything that can be done to decrease the information overload of the developers working directly on the firewall's base function is a good thing.

For some users, having a file server on the firewall may be a good thing. Or using it as a media player also. But it should not take away from the time the core developers are putting into the project.

Personal example. I have a script I'm working on; basically a port of a little tool we use at our business that tracks the maintenance done on our systems. I want that information for the routers also. And I may one day offer it to anyone else who needs it (once I get some bugs worked out of it). But, I don't feel I should ask any of the core developers to help me get it working; you are working on the core produc t.

So, yes, I think 3rd party developers, of which I would be a member, should be singled out as NOT core contributors. I'm doing it for my own benefit and any benefit to anyone else would be secondary. And it does not enhance the core functionality of the system at all.

...

...

But before anything is added to the core project, ask the question "does it enhance IPFire as a vpn/firewall/router" and if the answer is no, then don't include or support it. Let the third party developers do that.

Let the few core developers we have get back to making IPFire the great project it is.

Get back?! oO

Smart-#@$. You know what I mean. Spend more time developing and less time administrating things not directly related to the core product.

Rod

...

-Michael

...

Rod

On 01/19/2016 02:56 PM, David J. Allen wrote:

...

While I am only a user, I am on this list so I can keep up with the progress and tone of the project. One can tell a lot about the health of the developer community involved in a project and thus the health of, and likely future of the project itself (e.g. likely to improve, getting stale, dying).

So my comments should be taken in that context: one user's perspective.

On 01/18/2016 05:16 PM, Michael Tremer wrote:

...

Hello,

I am actually at a point now where I think we need to talk about this. A lot.

So many people have been starting to contribute to this project - or as I sometimes see it - to parallel projects. Projects that are developed in parallel to the main distribution. Projects that have different goals or are at least from my perspective heading into a different direction.

The mail proxy/mail server/web mail project is one like these. There are also others like multiple versions of the update accelerator and some more.

I use IPfire intentionally and *only* because it is a router/firewall, and a good one. I am /not/ interested in it as an alternative Linux distribution, or as web server, development platform, DNS server, printer server, graphics workstation, or gaming zone.

It's my router. Period. I don't need or want other non-router, non-firewall crap added to the recipe. If I wanted a Swiss Army knife distribution, there are plenty of others to look at*.

"Do one thing, and do it well".

*I'm already not happy that IPfire has followed the herd into Systemd-land, since that path will lead (has lead) to more bugs and (hidden) security holes, as there are virtually no reliable security audits or real testing done by the ignorant "Change-for-change's -sake hipsters developing Systemd. However I can understand why you have gone that way, given that you depend on upstream code for most of your core systems, and it is now pretty much impossible to remove systemd's tendrils from even userland code ("One ring to bind them all").

And now that pretty much every Linux distro is defacto a Redhat/Fedora distro, you have no choice.

...

These changes are never submitted on here. There is not even a conversation on here about that being a goal. Despite me having multiple chats with people about how this process works and that they want to do it, soon-ish.

So here we are. Months later. With no progress at all.

So, then just ignore these "parallel" projects. They may be parallel in that they use IPfire as their code base, but they are, in my opinion, *not* Ipfire and should not claim to be.

...

Instead I am getting requests and bug reports for that software that I am not involved with at all. People tell me that bugs are fixed there or that there are features available they want to use. They ask when this will be available in the distribution.

I don't have an answer to that. And what is even worse is that right now I am too tired to look into this.

Again. I suggest you just ignore those requests in as tactful manner as possible. Tell them to talk to the hand.

Why should you be responsible for someone's fork of /your/ project? Do you feel obligated to answer questions about any other distro (and Ipfire really /is/ a Linux distribution)?

...

These projects have diverted a lot in that sense that an easy merge is no longer possible. It will take a lot of work to split up the changes, test them, confirm that they work, do QA and then release them. This process itself is not foolproof and we are not getting a lot of feedback. We just get the backlash when something is not working properly. It will be very tough.

Very tough *and* very unnecessary. Don't do that work. If if diverts your attention from Ipfire-the-router, then eventually if will negatively affect the quality of your code, and robustness of Ipfire. The last thing I want to use is a poorly built router/firewall.

...

Working on these changes step by step would have certainly avoided getting to this state. Now we are at it. Frankly, I do not know what to do.

Such work would still have served no legitimate purpose in the context of a secure software router.

What to do? Easy. Get back to your roots or risk losing users.

...

I will certainly not sit down and take these things apart myself. I have actually not much interest in working on these things any way. Cleaning up after somebody else won't be my main job for the next few weeks. That is partly because I don't want to and partly because that won't work any way. It is not my code.

There. You've said. That's all the reason you need right there. No need to apologize or wring hands over that kind of honesty.

...

The other option would be just to leave these projects as they are. That may either be getting old and rot in a git tree. That may either be them becoming something else. But I do not think that any of these is the best option for the IPFire project as a whole. I am very much interested in keeping that as the main target of my work.

How about just kick non-router/firewall-related projects to the curb.

Tell those who wish to add non-Ipfire cruft to go start their own distributions, set up their own servers, support teams, build up their own user community, and distribution, marketing, infrastructure, and all the other shit it takes, on their own dime.

...

And that might me or other IPFire developers to do the same work again. In this specific example update apache. From my point of view that only wasted valuable developer time. In both projects. That can't be the ideal.

So I would like to hear that from the people who are working on these parallel projects what they are intending to do and what they are expecting from me/the other developers. I honestly do not know if you think yourself that this is an issue, too. So let's have a productive discussion about that. I am expecting some answers...

Best, -Michael

You seem to have made what sounds like a disclaimer of your responsibility for what amounts to non-Ipfire (the concept) code. Why stop at halfway. Just do it:

Tell us "IpFire is a software router and firewall. That's it. It hopes to be the best in class at what it's intended to be. Nothing less. If you want something other than a world-class router and firewall, go somewhere else. If you want to help us in /our/ goal, then welcome aboard."

I can tell you that as a user, I know what *I* want from a router-firewall. I want rock solid security. I want robustness. I want a reasonably small footprint. I want the best possible performance. I want maintainability. I want it to just run and do the job it is designed to do. Nothing less, and certainly *nothing more*.

If I can't get that from IPfire, I'll go somewhere else. You have some good competition. In light of recent events in the Linux world *cough*cough*systemd* you're already at risk of losing users to similar BSD-based utilities.

And I still have an expensive, and very good appliance router -firewall sitting on the shelf which is not very happy about being replaced by IPfire. ;)

Just my opinion as a user.

Best Regards, David.

[snip]

Hello,

so to put an end to this discussion (I think we have heard the opinions of everyone who this matters to), I would like to quickly recap and propose some actions we/I will now take.

So Marcel (aka gocart on the forums) has unfortunately contacted me privately because he doesn't want to discuss this on this mailing list for several reasons. He allowed me to publish the content of that conversation. I won't post the full text (it is in German any way), but pick some points that I found interesting.

The first of the reasons why he is not taking part in this conversation on this list is that there is a language barrier and secondly he finds this list "useless". The latter one of these left me quite puzzled. I expressed my disappointment about that and asked again that he would think about it but there has been no reply.

He agrees that there have to be rules when many people are working together, but he does not accept ours. Even having this debate about these rules is a waste of time to him. It actually is, but rules have to be set up and and they have to be challenged from time to time.

Upstreaming work is a matter of leaving it in a git repository until somebody takes over. He is refusing a discussion about his work.

Just to remind you: This was never about just him. There are other parallel projects. He is just the only person who voiced himself a little bit. The others didn't.

So I come to my personal conclusion that I will just leave the stuff as it is. I won't talk with these people as there is clearly no point. I won't feel a bit responsible for what they are doing there.

If someone wants to take their stuff and post it to the list in an orderly fashion that is something else. Maybe these people can agree that one member of the team is talking to the rest of the developers as a spokesman. I find that just silly, but there might be other ways.

For me, stuff happens on this list. Nowhere else. Period.

The other consequence I am taking is to rename the development area on the forums. My first idea was to just get rid of it, but I guess people will be posting their stuff in other sub-forums then. So it will just be renamed to clearly state that this is *not* the place where development happens so that nobody can complain that "the developers" don't reply to their posts. There is this list. There is Bugzilla. These are the places to go.

I hope that these changes will improve the situation. I am in no way trying to deter those contributors from contributing to this project. I am trying to do the opposite which is to steer them towards contributing their patches in a way that we can review them, improve them if necessary, and then merge them into the distribution so that IPFire becomes better. This process however needs to follow rules and it appears that we have to enforce those even more.

Feel free to comment on this, but please keep it short if you can because I want to focus on other things. Just in case someone is interested in the PMs from Marcel let me know and I will post them, too.

Best, -Michael

Morning guys,

let me have a few words on this subject …

1. The problem startet with the development section of the forum (offered even in two languages - german and english). This implies that development of IPFire as well as add-ons is taking place there. Far later someone might realize, that there is another place (this mailing-list) where the actual development evolves.

2. What I have seen as answers on this mailing-list, the majority just wants a secure, ip-table based router with an web-interface. If that is the case, at least 80% of the current add-ons should be kicked out. Even quite a lot of the so called core is obsolet.

3. Marcel has clearly marked our development as ‚project‘. He even wrote a nice (not 100% finished yet) installer script to add and remove the functionality of the project(s) to IPFire. As far as I know, neither Marcel or anybody else of the people involved in the project have asked for help from the core developers (who ever they are …) or requested integration of the project into IPFire.

4. If you like or not, the language barrier is there. You can actually see it in this discussion. I am pretty sure, some expressions weren’t meant as they were - harsh. Talking about technical features in a foreign language is a total different thing than to express yourself or your opinion about something.

Michael, I hope you can contemplate about your conclusion, may be even think about dropping the mailing-list instead. Just in case you are sticking to the mailing-list and this procedure of development of IPFire, I kindly ask you where can I find the rules and procedures of involvement in writing (please don’t answer wiki.ipfire.org http://wiki.ipfire.org/ …).

BTW - I am very interested about the development of IPFire v3. So far I haven’t been able to find much about it beside some sources in the git - is there another place I should go ??

brgds and have a nice weekend Dirk

Am 23.01.2016 um 03:19 schrieb Michael Tremer michael.tremer@ipfire.org:

Hello,

so to put an end to this discussion (I think we have heard the opinions of everyone who this matters to), I would like to quickly recap and propose some actions we/I will now take.

So Marcel (aka gocart on the forums) has unfortunately contacted me privately because he doesn't want to discuss this on this mailing list for several reasons. He allowed me to publish the content of that conversation. I won't post the full text (it is in German any way), but pick some points that I found interesting.

The first of the reasons why he is not taking part in this conversation on this list is that there is a language barrier and secondly he finds this list "useless". The latter one of these left me quite puzzled. I expressed my disappointment about that and asked again that he would think about it but there has been no reply.

He agrees that there have to be rules when many people are working together, but he does not accept ours. Even having this debate about these rules is a waste of time to him. It actually is, but rules have to be set up and and they have to be challenged from time to time.

Upstreaming work is a matter of leaving it in a git repository until somebody takes over. He is refusing a discussion about his work.

Just to remind you: This was never about just him. There are other parallel projects. He is just the only person who voiced himself a little bit. The others didn't.

So I come to my personal conclusion that I will just leave the stuff as it is. I won't talk with these people as there is clearly no point. I won't feel a bit responsible for what they are doing there.

If someone wants to take their stuff and post it to the list in an orderly fashion that is something else. Maybe these people can agree that one member of the team is talking to the rest of the developers as a spokesman. I find that just silly, but there might be other ways.

For me, stuff happens on this list. Nowhere else. Period.

The other consequence I am taking is to rename the development area on the forums. My first idea was to just get rid of it, but I guess people will be posting their stuff in other sub-forums then. So it will just be renamed to clearly state that this is *not* the place where development happens so that nobody can complain that "the developers" don't reply to their posts. There is this list. There is Bugzilla. These are the places to go.

I hope that these changes will improve the situation. I am in no way trying to deter those contributors from contributing to this project. I am trying to do the opposite which is to steer them towards contributing their patches in a way that we can review them, improve them if necessary, and then merge them into the distribution so that IPFire becomes better. This process however needs to follow rules and it appears that we have to enforce those even more.

Feel free to comment on this, but please keep it short if you can because I want to focus on other things. Just in case someone is interested in the PMs from Marcel let me know and I will post them, too.

Best, -Michael