Re: The parallel projects (was Re: Apache 2.4 and php 5.6 test branch)

Re: The parallel projects (was Re: Apache 2.4 and php 5.6 test branch)

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 8590 bytes --]

Hello,

On Sat, 2016-01-23 at 09:23 +0100, Dirk Reitz wrote:
> 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.

I do not get why you are going on about this. It is perfectly fine that
you are having your space there where you do your things.

I just pointed out (repeatedly) that this is not the place where I am
getting involved.

> 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.

That is a different topic. IPFire is what it is right now and it will
remain to be that.

> 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.

I neither do get why you are going on about the wording. I guess what
you are having there is a "project". I would call it a project. Maybe
you should finally accept that is not only about the mail server/proxy.
There is also multiple versions of the update accelerator that are
being developed independently from each other. Hence I called this
thread "parallel projects" because those are developed in parallel to
each other.

People who have been involved in your "project" or conversation reached
out to me and did in fact ask for my help, when this will be merged and
asked me to coordinate. I declined for the most part.

> 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.

I do not deny it but I certainly don't like it, indeed. I think
learning a language is something everyone can do though.

As you are making this all about the mail server project, Marcel mailed
with other people in English. However, he just does not want to take
part in a discussion on here as he said to me in private. That is a
completely different thing and you cannot use that as an argument for
the language barrier.

> Michael, I hope you can contemplate about your conclusion, may be
> even think about dropping the mailing-list instead.

That is not an option at all. The developers I have spoken with want
this list and they like it. So it is not just me thrusting something
upon all of the others - in case it came across like this.

> 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 …).

Sure, the starting point for this is here:

  http://wiki.ipfire.org/devel/start

Where you will find about how to get in touch with the developers 

  http://wiki.ipfire.org/devel/contact
  http://wiki.ipfire.org/devel/mailing-lists

There is also a quick paragraph about where to report bugs and where
*NOT* to report bugs:

  http://wiki.ipfire.org/devel/bugzilla

Despite that we do not have a strict rule book where it says how we
should treat each other as I think that is not required. Many of these
rules are unwritten as they are common sense. Like Kant.

And as you guys know about one of them already, I would like you to
remind to obey that one. We talk in English on this list. The vast
majority of the people subscribed here do *NOT* speak German.

And an other reminder. Information on how to submit patches can be
found here:

  http://wiki.ipfire.org/devel/submit-patches

> 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 ??

This list is the place to go. The biggest part of development is taking
part off list in personal conversations (as in we are talking on the
phone). This is not ideal, but it is how it has evolved. I am trying to
put as much on this list as possible. Despite that there is the bug
tracker and we have a monthly telephone conference.

And as a final comment I can only recommend to ask. I am not expecting
from anyone to know all the things. Search the archive of this list if
something has been asked before. If not, feel free to ask.

Best,
-Michael

> brgds and have a nice weekend
> Dirk
> 
> > Am 23.01.2016 um 03:19 schrieb Michael Tremer <
> > michael.tremer(a)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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: The parallel projects (was Re: Apache 2.4 and php 5.6 test branch)

[R. W. Rodolico]

[-- Attachment #1: Type: text/plain, Size: 3643 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Understood.

On 01/22/2016 08:19 PM, Michael Tremer wrote:
> 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
> 

- -- 
Rod Rodolico
Daily Data, Inc.
POB 140465
Dallas TX 75214-0465
214.827.2170
http://www.dailydata.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlajKmwACgkQuVY3UpYMlTTHHwCeKpc+dt23b2ptFpQqq3FVzhtL
QEUAnAi/p9VEt0SdJREp8RKF8/K66mw0
=ZufT
-----END PGP SIGNATURE-----

Re: The parallel projects (was Re: Apache 2.4 and php 5.6 test branch)

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 2279 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: The parallel projects (was Re: Apache 2.4 and php 5.6 test branch)

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 7740 bytes --]

Hi,

On Wed, 2016-01-20 at 08:50 +0100, ummeegge wrote:
> Hi all,
> 
> Am 19.01.2016 um 12:41 schrieb Michael Tremer <
> michael.tremer(a)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 agree with that it is always hard to get in touch with the right
people and that many people want to be really sure they did everything
right. They are too afraid to make mistakes. That is on them I suppose.
I cannot repeat myself enough to share your work even if it is not
perfect, yet, and even if you have many questions. Doing mistakes is
normal and talking about them avoids some.

The language barrier is a second thing. However I think that everyone
can do this. One just has to start and then learn to become better with
reading and writing English.

Marcel got in touch on the forums about this matter where he sent me a
private message. In that one he signals that he has no interest what so
ever in this mailing list and no interest what so ever in posting
patches on here. *That* is a completely different thing which I cannot
accept at all.

> 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.

I haven't had any coding work with this at all. I haven't looked at the
git branches because at a first glance this is just a mess and it is
quite pointless to find out what is going on without putting too much
time info this.

Nobody of the people who are involved in this mail proxy/server project
have been in touch with me except you.

Other people have been trying to extract some parts from the Git branch
with help of the original developers and make them ready to be merged
into the main distribution which completely failed.

> 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 ?

I do not see why it is not possible to have a conversation on a mailing
list just in the same way you are having that on the forums.

If someone doesn't agree with the emails being sent to him, just
unsubscribe. Nobody is forced to stay on this list. Nobody is even
forced to read all the emails. But if you want to have a word and if
you want a peer-reviewed distribution, there must be a place where that
will happen.

> > 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 ?

The current state is that Marcel deleted the branch where he worked on
that. It seems that all the effort that was put into that was for
nothing.

The reason for that might have been a misunderstanding, but I do not
know to whom he was talking (not to me) and what was said, because that
didn't happen in public on this list, but was in private.

> > 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.

I didn't assume that anyone is trying to make things worse
deliberately.

> 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.

I didn't consider them to be parallel projects that fall into this
category which is supposed to be merged right away. This is a test and
you guys play around with that. If that is supposed to be merged is a
different thing since there needs to be a group of people who are
interested in using this and willing to maintain the package.

An update of essential core components is something different though.

Best,
-Michael

> 
> So far from here.
> 
> Greetings,
> 
> Erik
> 
> 
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: The parallel projects (was Re: Apache 2.4 and php 5.6 test branch)

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 16461 bytes --]

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]
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: The parallel projects (was Re: Apache 2.4 and php 5.6 test branch)

[ummeegge]

[-- Attachment #1: Type: text/plain, Size: 4846 bytes --]

Hi all,

Am 19.01.2016 um 12:41 schrieb Michael Tremer <michael.tremer(a)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




[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

Re: The parallel projects (was Re: Apache 2.4 and php 5.6 test branch)

[R. W. Rodolico]

[-- Attachment #1: Type: text/plain, Size: 15182 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



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.

> 
> 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?

> 
> 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]

- -- 
Rod Rodolico
Daily Data, Inc.
POB 140465
Dallas TX 75214-0465
214.827.2170
http://www.dailydata.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlae3LMACgkQuVY3UpYMlTRZvgCeMaRsY2CalLMccQL0GoxRcQbQ
hHsAmwflCFokRiAAHBXzudyBZS8WJlY2
=JV1I
-----END PGP SIGNATURE-----

Re: The parallel projects (was Re: Apache 2.4 and php 5.6 test branch)

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 13224 bytes --]

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]
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: The parallel projects (was Re: Apache 2.4 and php 5.6 test branch)

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 10703 bytes --]

Hi,

On Tue, 2016-01-19 at 12:56 -0800, 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.

Thanks very much for commenting. 

> 
> 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.

Well, that is what we are actually doing in IPFire 3. It has the
possibility to use external repositories better and it is more stripped
down.

However, in 2016, we won't simply build a router. We will have more
functionality in there that is used and needed by many people like
proxies for the web, DNS, etc.

What should be part of that and what not is a completely different
discussion though.

> 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".

We are not aiming to replace any major distribution here.

> *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").

We intentionally migrated to systemd. I guess we have been the second
distribution to do that after Fedora. There are many good reasons to do
that. To calm you all a little bit, we are using it as an init-system
only and disabled all the stuff that should not belong in there for our
purposes.

http://git.ipfire.org/?p=ipfire-3.x.git;a=blob;f=systemd/systemd.nm;h=3
5d2b0bef40b7234cf054489395d1d5b0a0f43e7;hb=HEAD#l60

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

Yeah, but to make a quick point here: They are pretty much the biggest
and only organisation that is actually funding this work. They are also
the competition. So there is no way to develop an alternative as a side
-project. And unfortunately there is no other source that is funding
alternative free software projects. They are building a big monopoly
here and I don't like this at all.

Although I would like to talk about this in length, this is not the
time and place to do that. So let's leave it to that.

> 
> 
> > 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.

That is one option. To me that comes with the big downside that it
won't engage people to contribute to the actual IPFire project.

There can certainly be other projects that build on IPFire, but they
need to be sure to contribute back to the main distribution. Without
any talking this can't be working 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.
> 
> Again. I suggest you just ignore those requests in as tactful manner
> as 
> possible. Tell them to talk to the hand.

I usually do this. But that still keeps me busy at times.

> 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)?

People out there don't know the difference. It is a bit like the
grsecurity issue. People claim the name although there is something
else inside their systems working. Brad didn't like that and took some
action. I do not want to get into that situation.

So for many IPFire is one big thing and they just email me. I don't
respond to most of the personal support queries any way, but that
doesn't bother them.

> > 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 am not targeting to have as many users as we can get. That would
spoil me making the right decisions. Some people want feature X.
Denying that will make some people go and search for alternatives, but
that is the way it is.

I have been heavily refusing to add SSL bump to the proxy that teared
many people away. However this would have created many security issues
that I don't want to constantly fix and that can't be fixed any way
since they are in the design of the feature. A feature that makes no
sense any way.

I sometimes take the non-intuitive route. If this was a commercial
product I would have implemented that feature and earned the money for
it.

> > 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.

We pretty much did that in IPFire 3. That leads to that we don't get
any support there from outside people.

> 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]

-Michael

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: The parallel projects (was Re: Apache 2.4 and php 5.6 test branch)

[Larsen]

[-- Attachment #1: Type: text/plain, Size: 196 bytes --]

On Tue, 19 Jan 2016 22:59:50 +0100, R. W. Rodolico <rodo(a)dailydata.net>  
wrote:

> I agree that IPFire is, for me, a firewall/vpn/router. I really have
> very little use for anything else.

+1

Re: The parallel projects (was Re: Apache 2.4 and php 5.6 test branch)

[R. W. Rodolico]

[-- Attachment #1: Type: text/plain, Size: 9880 bytes --]

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]

-- 
Rod Rodolico
Daily Data, Inc.
POB 140465
Dallas TX 75214-0465
214.827.2170
http://www.dailydata.net

Re: The parallel projects (was Re: Apache 2.4 and php 5.6 test branch)

[David J. Allen]

[-- Attachment #1: Type: text/plain, Size: 7192 bytes --]

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]

Re: The parallel projects (was Re: Apache 2.4 and php 5.6 test branch)

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 10220 bytes --]

Hi,

On 19/01/2016 10:18 AM, ummeegge wrote:
> 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.

Indeed.

> 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.

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.

> 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.

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.

> 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.

Does anyone know if they are even all subscribed?

> 
> Some thoughts from my side.
> 
> Greetings,
> 
> Erik

-Michael

> 
> Am 19.01.2016 um 09:41 schrieb Dirk Reitz <dirk.reitz(a)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(a)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

Re: The parallel projects (was Re: Apache 2.4 and php 5.6 test branch)

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 7292 bytes --]

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(a)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

The parallel projects (was Re: Apache 2.4 and php 5.6 test branch)

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 5461 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]