From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: The parallel projects (was Re: Apache 2.4 and php 5.6 test branch) Date: Tue, 19 Jan 2016 11:41:11 +0000 Message-ID: <8425d3258a69433b15c21671732bc584@mail01.ipfire.org> In-Reply-To: <24C74A6E-65D3-471E-8F83-9EFABBD57DC4@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4868724508604373472==" List-Id: --===============4868724508604373472== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Hi, On 19/01/2016 10:18 AM, ummeegge wrote: > Hi all, > to leave a fast insight of my approach in developing some new ideas or > features for IPFire, i tried normally to find people who are > interested in a specific feature which i found useful, so if there > were some responses i tried to go in a kind of testing scenario where > the community could also brought on new ideas, own development, > possible bugs or problems but also to collect material and ideas or > possible extensions for a documentation in the wiki. This procedure > brought in the past some usable results in my opinion where it was > possible with relatively few bugs, a more detailed documentation and > some more people from the community which are earlier integrated in > such projects to deliver a better result to IPFire where it could > finally be reviewed. Indeed. > This process do not work always in a straight way or brings sometimes > to many problems up where the second view figures too much problems > out and the project stucks or comes to an unforeseeable end which is > sometimes a pity cause of the invested work but may better in some > cases. When starting with something we often don't know where we will end up. That's quite normal. However going to the very end won't work either. > Regarding to the Mailproxy/Mailserver project i tried to help > interested people out as far as i could to support also similar > intends but also to find with more people ways to be maintainers for > some very old and outdated IPFire Addons. Postfix is a kind of big > regarding to the update scenario cause a lot of basic components are > involved in that process (Perl, PHP, Apache, Amavisd, Spamassassin, > BerkeleyDB to name a few). Just to make it a little more > understandable what happens in this project specifically, there was > and i think is the willingness to develop a working environment where > all updated packages comes together for testings before a merge > request but also a proper configuration are in place to went through > different testing environments and get also a better/deeper insight > and feedback if things are working and if not, how could it be made > better. We can't ship that all in just one update. There are many reasons for that. 1) The updates will get too big to ship. 2) The updates will be too big to get tested. Not many people are engaging in this any way. And we actually don't need to have this so stressful. Some things of that like PHP can be updated individually or with fewer dependencies. So we start with that and go on from there. > As time goes by, a lot of updates has been done in that topic and the > current state there is a kind of stable i think. In my point of view > there is the need that possible maintainers of the, let´s say, mail > project find together with the core developer a structure how to > deliver all that in smaller steps which are useful and good for the > IPFire project. > > So from my side, i can imagine to support this process further if > there is the will for cooperation on both sides and ideas how we can > proceed with this. I think also that it is very important that > possible maintainers of such projects are present also in this > environment (developer mailinglist) to find together a efficient > progress of development. Does anyone know if they are even all subscribed? > > Some thoughts from my side. > > Greetings, > > Erik -Michael > > Am 19.01.2016 um 09:41 schrieb Dirk Reitz : > >> 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 >> : >> >> 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 --===============4868724508604373472==--