> But there still have not been any discussion on the webmaster list, > which is where we discuss such things at all, that is what baffles me > the most that such a move has not even been mentioned here, which is > where the development of the website systems takes place.
Acknowledged. Sorry for not forwarding this here sooner. I kind of assumed this was resolved and is only waiting for a merge and adjustments. Then, let's see what we can do here then about that if anyone disagrees with using Composer locally (please note that using Composer in production will need a discussion if not even omitting it as a deployment step altogether because it's not a trivial task for server nor a deployment). I can reopen this discussion for sure and we can go through it. > That is fine and all that PEAR itself is getting obsolete, but if we > break down the dependencies then its all native PHP besides the > Text_Diff component you mentioned. I don't really think anyone uses > this as a standalone bug tracker anyway as its so baked into the > PHP.net systems and not customizable so I kinda fail to see the point > when its only running on one machine. I'm sorry for the blantness but > it seems a bit pointless to me. I mean sure if you are installing and > developing locally but its such a minority. Option to install development dependencies locally, for example phpunit and some other possible things (database fixtures etc) is actually a major bonus feature for this app. We can also hook travis CI into this one day and more. Theoretically, you can install entire app locally with only a single "composer install" and it takes care of several steps for the contributor. I understand that this is an installation used on bugs.php.net only but this doesn't mean that convenience of setting such app locally or in a Docker container should be omitted with removing Composer. > As for CS, we have always refered to the PEAR Coding standards[1] > (with a minor exception to the examples in the PHP documentation as > noted in the tutorial[2]), and I don't see any discussion about > changing this anywhere on the discussions nor making it for web/bugs > only so far. > > I don't want this to come out as too negative, whilst I do appreciate > the care being taken to update the system, I just prefer we do it with > discussions where we all can chime in, I do miss most of them as I'm > only subbed to the php-src on github (webmaster ML is the official). > > [1] http://pear.php.net/manual/en/standards.php > [2] http://doc.php.net/tutorial/style.php You don't come negative. Thanks for this info and pointing it out. And, I think that's mostly solved then and it's very the same as PEAR coding standards. Actually, PEAR's coding style would be a great addition in the current files. Current .editorconfig file uses exactly the same configuration as PEAR's instructions: - spaces as indentation, no tabs - LF as line ending - UTF-8 file encoding - final new lines are also mentioned in a way (The only additionaly feature is trailing whitespaces trim which is something logical on its own, I think) The EditorConfig doesn't deal with anything else here actually :) other tools like code fixers etc. can be adjusted to use something like PEAR's coding style also but that's none of the changes mentioned yet nor even planned from my side as some sort of conspiracy or anything. I just locally run php-cs-fixer on the code that I produce from time to time. That's it. -- Peter Kokot -- PHP Webmaster List Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
