Dear Michael and all other developers,

I am sorry to realize at least some frustration out of your post.

This has never been our intention and still is not. Although we got some hints/informations regarding the developer mailing list, we thought it would be enough to show our projects and progress in the developer part of the forum - obviously wrong, our fault !
Our intention was to expand the functionality of ipfire as a central part of the network - therefore we started the development of our projects. In addition we wanted to help future development of ipfire - we hoped that some of our work could be reused, but we never expected anything from you Michael or other developers.

As Marcel is not so familiar writing in english, I offered to do this instead (for the mail proxy/mail server).

I agree that our projects have diverted a lot from ipfire, but I am confident we are able to sort it out.
Please let me know, what I can/should do

best regards
Dirk 



Am 19.01.2016 um 02:16 schrieb Michael Tremer <michael.tremer@ipfire.org>:

Hello,

I am actually at a point now where I think we need to talk about this.
A lot.

So many people have been starting to contribute to this project - or as
I sometimes see it - to parallel projects. Projects that are developed
in parallel to the main distribution. Projects that have different
goals or are at least from my perspective heading into a different
direction.

The mail proxy/mail server/web mail project is one like these. There
are also others like multiple versions of the update accelerator and
some more.

These changes are never submitted on here. There is not even a
conversation on here about that being a goal. Despite me having
multiple chats with people about how this process works and that they
want to do it, soon-ish.

So here we are. Months later. With no progress at all.

Instead I am getting requests and bug reports for that software that I
am not involved with at all. People tell me that bugs are fixed there
or that there are features available they want to use. They ask when
this will be available in the distribution.

I don't have an answer to that. And what is even worse is that right
now I am too tired to look into this.

These projects have diverted a lot in that sense that an easy merge is
no longer possible. It will take a lot of work to split up the changes,
test them, confirm that they work, do QA and then release them. This
process itself is not foolproof and we are not getting a lot of
feedback. We just get the backlash when something is not working
properly. It will be very tough.

Working on these changes step by step would have certainly avoided
getting to this state. Now we are at it. Frankly, I do not know what to
do.

I will certainly not sit down and take these things apart myself. I
have actually not much interest in working on these things any way.
Cleaning up after somebody else won't be my main job for the next few
weeks. That is partly because I don't want to and partly because that
won't work any way. It is not my code.

The other option would be just to leave these projects as they are.
That may either be getting old and rot in a git tree. That may either
be them becoming something else. But I do not think that any of these
is the best option for the IPFire project as a whole. I am very much
interested in keeping that as the main target of my work.

And that might me or other IPFire developers to do the same work again.
In this specific example update apache. From my point of view that only
wasted valuable developer time. In both projects. That can't be the
ideal.

So I would like to hear that from the people who are working on these
parallel projects what they are intending to do and what they are
expecting from me/the other developers. I honestly do not know if you
think yourself that this is an issue, too. So let's have a productive
discussion about that. I am expecting some answers...

Best,
-Michael

On Wed, 2016-01-13 at 15:51 +0100, Daniel Weismüller wrote:
Hi Marcel

And a happy new year. ;-)

I'm a bit sad about that I didn't get an answer from you.
A few minutes ago I've taken a look to your git and notices that you
have removed the new-apache-php branch.

I know it would be bit work to do to separate every part of your
existing work into their own branches but I really tried to explain
you the requirement.

Finally I hope that you are still interested to share your work with
the project?

yours
Daniel

Am 21.12.2015 um 15:43 schrieb Daniel Weismüller:
Hi Marcel

Sorry for the late answer.

I've taken a look on your new branch.

I'm really saddened to have to say that we still can't use it.

We can't use update packs like you build them. We need every single
thing in his own branch.
I know it is much more effort but at least it is much better
because they won't collide with other updates.
Another advantage is that each part is individually maintainable.

So it would be really great if you could split your work into cutie
little pieces. :-)

Thanks a lot.

- Daniel

Am 04.12.2015 um 19:22 schrieb Marcel Lorenz:
Hi Daniel

I have created a test branch new-apache-php.
With berekeley 6.1.26 and ICU 56.1  for apache.
mcrypt is a prerequisite for php.

Apache  ./configure log :

checking db6/db.h usability... yes
checking db6/db.h presence... yes
checking for db6/db.h... yes
checking for -ldb-6.1... yes
checking for Berkeley DB... found db6
checking for default DBM... sdbm (default)
 setting LDADD_dbm_db to "-ldb-6.1"

Commit text:
Update to new Apache 2.4 and PHP 5.6

Apache 2.4.17
PHP 5.6.16
mcrypt 2.6.8 (new)

Comments:
Apache works in event mode and uses Berkeley DB6
PHP is multithreaded

Apache config folder is changed from /etc/httpd/conf/ to
/etc/httpd/
Apache 2.4.x need this change. The sysconfdir layout entry has no
effekt more.
All relevant lfs and rootfiles are updated (owncloud,
naigos(sql), phpSANE, icniga, cacti)

http://git.ipfire.org/?p=people/mlorenz/ipfire-2.x.git;a=shortlog
;h=refs/heads/new-apache-php

I have testet the iso from this branch. Owncloud,  cacti ,
icniga, naigos has yet to be tested..

Marcel