# Learning from Python: PEPping the PHP Development Process - Thread: https://externals.io/message/12367 - Original archive: https://news-web.php.net/php.internals/12367 - Started by Sebastian Bergmann on 2004-08-26T16:11:27+00:00 - Messages: 17 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #12367 — Sebastian Bergmann — 2004-08-26T16:11:27+00:00 URL: https://externals.io/message/12367#12367 At last weekend's EuroFoo [1] I attended Marc-Andre Lemburg's talk [2] on the Python development process. I really wish we had a process similar to Python's PEPs [3] [4] for PHP. Having guidelines for issues like adding a new module [5] or deprecating a module [6] not only makes the development consistent but also transparent to our users. Wishfully thinking, Sebastian (who knows that it might not be his place to call for a change like this given that he is not a core developer) -- [1] http://wiki.oreillynet.com/eurofoo/index.cgi [2] http://www.egenix.com/files/python/EuroPython2004-How-Python-is-developed.pdf [3] http://www.python.org/peps/ [4] http://www.python.org/peps/pep-0001.html [5] http://www.python.org/peps/pep-0002.html [6] http://www.python.org/peps/pep-0004.html -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/ --- ## #12369 — Rasmus Lerdorf — 2004-08-26T17:49:32+00:00 URL: https://externals.io/message/12367#12369 · In reply to: #12367 > At last weekend's EuroFoo [1] I attended Marc-Andre Lemburg's talk [2] > on the Python development process. > > I really wish we had a process similar to Python's PEPs [3] [4] for PHP. > > Having guidelines for issues like adding a new module [5] or deprecating > a module [6] not only makes the development consistent but also > transparent to our users. It smells a little too processy to me, but I wouldn't mind a system that borrowed some of the ideas. Like a single collection point for feature proposals and a common format for them. We could simply steal PEAR's PEPR infrastructure for this (http://pear.php.net/pepr/pepr-overview.php). -Rasmus --- ## #12370 — Sebastian Bergmann — 2004-08-26T17:53:42+00:00 URL: https://externals.io/message/12367#12370 · In reply to: #12369 Rasmus Lerdorf wrote: > It smells a little too processy to me, but I wouldn't mind a system > that borrowed some of the ideas. That is exactly why chose "Learning ..." and not "Adopting ..." :-) We should have a look at it and see for ourselves what could work for us. > Like a single collection point for feature proposals and a common > format for them. This would be a huge step forward, IMHO, as we would then have a central site to point users to in order to look up design decisions, etc. > We could simply steal PEAR's PEPR infrastructure for this I was thinking along the same lines. > -Rasmus Greetings, Sebastian -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/ --- ## #12371 — Greg Beaver — 2004-08-26T18:06:01+00:00 URL: https://externals.io/message/12367#12371 · In reply to: #12369 Rasmus Lerdorf wrote: > > > > […] > > > It smells a little too processy to me, but I wouldn't mind a system that > borrowed some of the ideas. Like a single collection point for feature > proposals and a common format for them. We could simply steal PEAR's PEPR > infrastructure for this (http://pear.php.net/pepr/pepr-overview.php). PEPr has been pretty useful, but there are some pitfalls with the current design of PEPr. It seems that in the proposal stage, most developers don't even notice a package. At the voting stage, the proposal can't be modified (for obvious reasons), and so many flame wars have erupted from those who have not noticed it versus those who have devoted lots of energy to it. Also, since developers tend to be gone occasionally, the voting period of 2 weeks can sometimes be too short to get a real sense of consensus. I'd say the best aspect of PEPr is the centralized location for all ideas. Using voting to make decisions is in my opinion somewhat of a failure though. Voting could more successfully be used to determine popularity/necessity of a feature or proposal (i.e. allow people with cvs accounts to not only vote, but to change their vote as they learn more about a feature). Then the developers can react better to the users' changing needs. Also, PHP has very active and clear leaders in Zeev and Andi, and so decision-making won't need to be as democratic as it might otherwise have to be. I don't mean to discourage the idea, but if you do decide to go with a PEPr-like system, it would be good to learn from PEAR's first go at it. Greg --- ## #12373 — Sterling Hughes — 2004-08-26T19:47:41+00:00 URL: https://externals.io/message/12367#12373 · In reply to: #12369 Rasmus Lerdorf wrote: > > > > > […] > >It smells a little too processy to me, but I wouldn't mind a system that >borrowed some of the ideas. Like a single collection point for feature >proposals and a common format for them. We could simply steal PEAR's PEPR >infrastructure for this (http://pear.php.net/pepr/pepr-overview.php). > > It smells a bit too processy anyway you swing it, and maybe I'm missing something, but I don't see any need: I'd like to see a problem before we attempt to fix it. -Sterling --- ## #12392 — Sebastian Bergmann — 2004-08-27T05:14:45+00:00 URL: https://externals.io/message/12367#12392 · In reply to: #12371 Greg Beaver wrote: > PEPr has been pretty useful, but there are some pitfalls with the > current design of PEPr. Most notably that everyone is allowed to vote ie. thinks his vote should matter? When it comes to voting I think it should not be democratic but meritocratic. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/ --- ## #12395 — Hartmut Holzgraefe — 2004-08-27T06:55:57+00:00 URL: https://externals.io/message/12367#12395 · In reply to: #12392 Sebastian Bergmann wrote: > When it comes to voting I think it should not be democratic but > meritocratic. whereas we now are mostly do-o-cratic (a nice term that came up at EuroFoo although i don't remember where i picked it up ...) -- Hartmut Holzgraefe At last weekend's EuroFoo [1] I attended Marc-Andre Lemburg's talk [2] > on the Python development process. > > I really wish we had a process similar to Python's PEPs [3] [4] for > PHP. > > Having guidelines for issues like adding a new module [5] or > deprecating a module [6] not only makes the development consistent but > also transparent to our users. What is wrong with how we currently do it? regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org --- ## #12398 — Christian Stocker — 2004-08-27T07:10:57+00:00 URL: https://externals.io/message/12367#12398 · In reply to: #12397 > > > > > […] > > > What is wrong with how we currently do it? Agreed. I don't like PEpr, I don't like the PEAR voting process and the PHP developement process works quite well how it is (I'm aware of the fact, the PHP wouldn't just take PEAR's model as-it-is, but nevertheless...). Actually, other people i talk to are always impressed, how this "chaotic", based-on-common-agreement developement process actually works at all ;) This doesn't stop us from having some PEP-like documents, which clearly define some common rules, but I fear we end up in heavy discussions on wording and details. See the PEAR mailinglists for an example ;) chregu -- christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71 http://www.bitflux.ch | chregu@bitflux.ch | gnupg-keyid 0x5CE1DECB --- ## #12399 — Sebastian Bergmann — 2004-08-27T07:10:57+00:00 URL: https://externals.io/message/12367#12399 · In reply to: #12395 Hartmut Holzgraefe wrote: > whereas we now are mostly do-o-cratic (a nice term that came up > at EuroFoo although i don't remember where i picked it up ...) Which is just colloquial for meritocratic, AFAICS :-) -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/ --- ## #12400 — Sebastian Bergmann — 2004-08-27T07:11:58+00:00 URL: https://externals.io/message/12367#12400 · In reply to: #12397 Derick Rethans wrote: > What is wrong with how we currently do it? We have currently nothing like it. Or if we do, I haven't notices it in the last couple of years. And if I haven't, chances are that our users haven't either :-) -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/ --- ## #12401 — Hartmut Holzgraefe — 2004-08-27T07:27:53+00:00 URL: https://externals.io/message/12367#12401 · In reply to: #12399 Sebastian Bergmann wrote: > Hartmut Holzgraefe wrote: > > > […] > > > Which is just colloquial for meritocratic, AFAICS :-) > No, as your vote doesn't get more important in general as you contribute. Instead you vote for a certain way of doing something and the most effective way of voting against this is to implement a different approach. (as far as i understood) PS: i remember now that the Skolelinux project came up with this term -- Hartmut Holzgraefe No, as your vote doesn't get more important in general as you > contribute. Instead you vote for a certain way of doing something > and the most effective way of voting against this is to implement > a different approach. (as far as i understood) Hm, I always thought that the concept you describe was called meritocracy because the value of your vote is based on the merit you brought to the project. Sorry for confusing this, Sebastain -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/ --- ## #12410 — Derick Rethans — 2004-08-27T07:56:12+00:00 URL: https://externals.io/message/12367#12410 · In reply to: #12408 > Christian Stocker wrote: > > […] > > Well, one reason might be no matter how fuzzy the process > there are some very clear metrics for the result, like > e.g. "compiles", "passes tests" or, a little more fuzzy > but still rather fact-based, "works". And you can apply > all these to different scales of changes. Combine this > with the fact that the effort needed to implement changes > does not include any noticable cost of creating a copy > first and you'll find that creating software is very > different to other forms of science, engineering and > art. We have some of this in our EXTENSIONS file in CVS. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org --- ## #12408 — Hartmut Holzgraefe — 2004-08-27T07:58:09+00:00 URL: https://externals.io/message/12367#12408 · In reply to: #12398 Christian Stocker wrote: > Actually, other people i talk to are always impressed, how this > "chaotic", based-on-common-agreement developement process actually works > at all ;) Well, one reason might be no matter how fuzzy the process there are some very clear metrics for the result, like e.g. "compiles", "passes tests" or, a little more fuzzy but still rather fact-based, "works". And you can apply all these to different scales of changes. Combine this with the fact that the effort needed to implement changes does not include any noticable cost of creating a copy first and you'll find that creating software is very different to other forms of science, engineering and art. > This doesn't stop us from having some PEP-like documents, which clearly > define some common rules, but I fear we end up in heavy discussions on > wording and details. See the PEAR mailinglists for an example ;) oh yes, the only list that i'm subscribed to but have activated the "mark message as read" option in the filter ;) -- Hartmut Holzgraefe Christian Stocker wrote: > > > […] > > > Well, one reason might be no matter how fuzzy the process > there are some very clear metrics for the result, like > e.g. "compiles", "passes tests" or, a little more fuzzy > but still rather fact-based, "works". And you can apply > all these to different scales of changes. Combine this > with the fact that the effort needed to implement changes > does not include any noticable cost of creating a copy > first and you'll find that creating software is very > different to other forms of science, engineering and > art. I wanted to compare it to other software projects (notably I spoked to some Mozilla guys about that topic and also some "commercial/proprietary" software developers), not to science et al. I'm an engineer by education, so I wouldn't dare to try to compare PHP developement process to eg. building a sewage plant (yeah, I learned how to do that ;) ) chregu -- christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71 http://www.bitflux.ch | chregu@bitflux.ch | gnupg-keyid 0x5CE1DECB --- ## #12412 — Jacques Marneweck — 2004-08-27T08:02:48+00:00 URL: https://externals.io/message/12367#12412 · In reply to: #12400 On Fri, 27 Aug 2004 09:11:58 +0200, Sebastian Bergmann wrote: > Derick Rethans wrote: > > […] > > We have currently nothing like it. Or if we do, I haven't notices it in > the last couple of years. And if I haven't, chances are that our users > haven't either :-) > We could make our own version of a proposal system for this sort of thing. Also our 'bugs' system could use a slight overhaul to support adding file attachments, and various other features. We could make feature requests sent via bugs end up with a tag on the front by the time it hits the mailing list. Also we don't keep easy records on how to find the design decisions, as on always has to end up digging around the mailing list archives. I have a project on my TODO list which is to allow news.php.net to allow searching of mailing list posts for a start, but I have not had sufficient time to get this off the ground. Also I'm planning on getting threading to work properly, so that one can see a list of threads for a post, and can go up / down the thread similar lists.mysql.com which would make it easier to follow threads and find things on the mailing lists. Regards --jm > -- > Sebastian Bergmann > http://sebastian-bergmann.de/ http://phpOpenTracker.de/ > > Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/ > > -- > > > > -- Jacques Marneweck http://www.powertrip.co.za/blog/