public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: The parallel projects (was Re: Apache 2.4 and php 5.6 test branch)
Date: Tue, 19 Jan 2016 23:25:45 +0000	[thread overview]
Message-ID: <1453245945.5665.196.camel@ipfire.org> (raw)
In-Reply-To: <569EB1D6.5040501@dailydata.net>

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

  parent reply	other threads:[~2016-01-19 23:25 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <56966461.3090401@ipfire.org>
2016-01-19  1:16 ` Michael Tremer
2016-01-19 20:56   ` David J. Allen
2016-01-19 21:59     ` R. W. Rodolico
2016-01-19 22:11       ` Larsen
2016-01-19 23:25       ` Michael Tremer [this message]
2016-01-20  1:02         ` R. W. Rodolico
2016-01-20 14:58           ` Michael Tremer
2016-01-19 23:05     ` Michael Tremer
2016-01-23  2:19       ` Michael Tremer
2016-01-23  7:23         ` R. W. Rodolico
     [not found] <C88CCB4C-7B6E-458A-9BCF-7A1AD320F99D@gmail.com>
2016-01-19 11:28 ` Michael Tremer
     [not found] <24C74A6E-65D3-471E-8F83-9EFABBD57DC4@ipfire.org>
2016-01-19 11:41 ` Michael Tremer
2016-01-20  7:50   ` ummeegge
2016-01-20 23:25     ` Michael Tremer
     [not found] <1453291479.2200.0@smtp.1und1.de>
2016-01-20 23:43 ` Michael Tremer
     [not found] <25A90500-70D9-4904-A434-6DE9AB6007FA@gmail.com>
2016-01-23 11:33 ` Michael Tremer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1453245945.5665.196.camel@ipfire.org \
    --to=michael.tremer@ipfire.org \
    --cc=development@lists.ipfire.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox