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

[Michael Tremer <michael.tremer@ipfire.org>]

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