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

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

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)

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

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

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

[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: 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)

[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: Re: The parallel projects (was Re: Apache 2.4 and php 5.6 test branch)

[Michael Tremer]

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

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