From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: The parallel projects (was Re: Apache 2.4 and php 5.6 test branch) Date: Wed, 20 Jan 2016 14:58:47 +0000 Message-ID: <1453301927.5665.206.camel@ipfire.org> In-Reply-To: <569EDCB3.4030805@dailydata.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6581559724941167094==" List-Id: --===============6581559724941167094== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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] > --===============6581559724941167094== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEKCmlRSWNCQUFC Q2dBR0JRSlduNkNvQUFvSkVJQjU4UDl2a0FrSC9NNFAvaTE0YXJqalkyL1NsVlhuQ0dHQVZYODEK aWlrSWFvTUZEeEUvSURvSVVjVzUxOE8yN04yWnBKTGUzZnVnYkQ3OG1UU3RqRlFLRjlkZjFxLzZa T2RsbUdLawoyMWdSdlRpaHRlcmZGNTE1T1pnY2x6dm5FK0QzSkljVGtqOUNsclFWZmVKRUVuR0ZU bFJQZ0NGbzRsMjQwSlVUCk1ubmthRFJxN1ZzZWZrTk1UYms5VE9za3ZjVG1vWjJwL1NaZndyZ1ZS U3d1WFVaVEt3ZnRINXVWZWFSaGZVbGIKZFNraUpPOXJYSnRtbk00VTVKbFRycWYwbnNMTFFSb0Yy TGtwT3NqT1o0bVBCeFdFYnRkYUQ0RTVsU0tCY0ovUwp5UE5aalJyMUVNVDZyREJ5NUppOTY5dGRY aFp3N2kzdU8vVWtISWxxdExwUmsyQjJaeVArcWJ2SkloU0MvZEs5ClltMnpaOTc5MTBucDdLa3pN UlRhODhqd2NkY1FINkJwK3hCZk5FRVhXZk5ubjJtUHN1YWRpM2pNOTZGa2d4eXkKNmppcGdMTDBh ZUwzQmxBeXo2RnRXbEtVclRISU1iNWZZbWxIL3BqYXJweWxOMmd0WEs4N2l0bGYwd1ArbUZwaApQ UC8wb2k0NnMzT1I4Uy9vajB3d1ZBNk9nTE9EUG9xSUo5YVJVQ09PSFpLd2drWkE1Z3AvMEpzNlJW Zkt0cWNJCllwMG9XdW5mRDRkTDBxRW5MWnB1djhoVXdqYVR6dHdvN1kxTlg2MzZldStCZFlIVUpY VkxTRG4raDFzN0NsdDgKMFpVS0V1d0ZpNjg5TSs4TWhZVUZFdzhPaHVHT1hvZFZiSVRjS2Q5TVIx MmhQakxiRGVkM0pDWTc3NkdYQW5jdwpodlNid0lZbkUyemduKzFseDNwdAo9ZDV1bAotLS0tLUVO RCBQR1AgU0lHTkFUVVJFLS0tLS0K --===============6581559724941167094==--