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/
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
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/
Rasmus Lerdorf wrote:
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).
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
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/
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 <hartmut@php.net
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/
Sebastian Bergmann wrote:
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 :-)
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 <hartmut@php.net
Hartmut Holzgraefe wrote:
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/
Rasmus Lerdorf wrote:
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).
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
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
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?
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
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 <hartmut@php.net
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.
We have some of this in our EXTENSIONS file in CVS.
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
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.
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
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/
On Fri, 27 Aug 2004 09:11:58 +0200, Sebastian Bergmann
sb@sebastian-bergmann.de wrote:
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 :-)
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/