Re: Re: [PHP-DEV] Learning from Python: PEPping the PHP Development Process

2004-08-28 Thread Wez Furlong
IMO, it makes sense to fold EXPERIMENTAL and CREDITS files into the
package.xml files that Hartmut added; they provide versioning and
status information.

Non-BC API changes require a bump to the API major number; a new major
in alpha or beta implies that the new API is subject to change until
it is marked stable.

--Wez.

On Fri, 27 Aug 2004 10:26:25 +0300, Zeev Suraski [EMAIL PROTECTED] wrote:
 I would like to get some feedback about my suggestion to move away from the
 simple 'experimental' status and dividing it into two - quality rating, and
 'API subject to change' tagging.  Does this make sense to anybody else?

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Learning from Python: PEPping the PHP Development

2004-08-27 Thread Hartmut Holzgraefe
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  [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


Re: [PHP-DEV] Learning from Python: PEPping the PHP Development Process

2004-08-27 Thread Derick Rethans
On Thu, 26 Aug 2004, Sebastian Bergmann 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.

What is wrong with how we currently do it?

regards,
Derick

-- 
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Learning from Python: PEPping the PHP Development Process

2004-08-27 Thread Christian Stocker

On 27.8.2004 8:59 Uhr, Derick Rethans wrote:
On Thu, 26 Aug 2004, Sebastian Bergmann 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.

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  |  [EMAIL PROTECTED]  |  gnupg-keyid 0x5CE1DECB
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


Re: [PHP-DEV] Learning from Python: PEPping the PHP Development

2004-08-27 Thread Sebastian Bergmann
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/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


Re: [PHP-DEV] Learning from Python: PEPping the PHP Development Process

2004-08-27 Thread Sebastian Bergmann
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/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


Re: [PHP-DEV] Learning from Python: PEPping the PHP Development

2004-08-27 Thread Hartmut Holzgraefe
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  [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


Re: [PHP-DEV] Learning from Python: PEPping the PHP Development

2004-08-27 Thread Sebastian Bergmann
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/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


Re: [PHP-DEV] Learning from Python: PEPping the PHP Development Process

2004-08-27 Thread Derick Rethans
On Fri, 27 Aug 2004, Zeev Suraski wrote:

 I would like to get some feedback about my suggestion to move away from the
 simple 'experimental' status and dividing it into two - quality rating, and
 'API subject to change' tagging.  Does this make sense to anybody else?

yes, sounds much better than added bureaucrazy.

Derick

-- 
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Learning from Python: PEPping the PHP Development Process

2004-08-27 Thread Hartmut Holzgraefe
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  [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


Re: [PHP-DEV] Learning from Python: PEPping the PHP Development Process

2004-08-27 Thread Derick Rethans
On Fri, 27 Aug 2004, Hartmut Holzgraefe wrote:

 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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Learning from Python: PEPping the PHP Development Process

2004-08-27 Thread Christian Stocker

On 27.8.2004 9:58 Uhr, Hartmut Holzgraefe wrote:
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  |  [EMAIL PROTECTED]  |  gnupg-keyid 0x5CE1DECB
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


Re: Re: [PHP-DEV] Learning from Python: PEPping the PHP Development Process

2004-08-27 Thread Jacques Marneweck
On Fri, 27 Aug 2004 09:11:58 +0200, Sebastian Bergmann
[EMAIL PROTECTED] 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/
 
 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 
 


-- 
Jacques Marneweck
http://www.powertrip.co.za/blog/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Learning from Python: PEPping the PHP Development Process

2004-08-27 Thread Ilia Alshanetsky
On August 27, 2004 03:26 am, Zeev Suraski wrote:
 Me too.
 I would like to get some feedback about my suggestion to move away from the
 simple 'experimental' status and dividing it into two - quality rating, and
 'API subject to change' tagging.  Does this make sense to anybody else?

As long as an extension can be marked as both, then this certainly sounds like 
a fine idea. 

Ilia

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Learning from Python: PEPping the PHP Development Process

2004-08-27 Thread Jason Garber
Hello Zeev,

  Makes sense to me.

-- 
Best regards,
 Jasonmailto:[EMAIL PROTECTED]

Friday, August 27, 2004, 3:26:25 AM, you wrote:


ZS I would like to get some feedback about my suggestion to move away from the
ZS simple 'experimental' status and dividing it into two - quality rating, and
ZS 'API subject to change' tagging.  Does this make sense to anybody else?

ZS Zeev

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Learning from Python: PEPping the PHP Development Process

2004-08-27 Thread Derick Rethans
On Fri, 27 Aug 2004, Hartmut Holzgraefe wrote:

 Ilia Alshanetsky wrote:
 I would like to get some feedback about my suggestion to move away from the
 simple 'experimental' status and dividing it into two - quality rating, and
 'API subject to change' tagging.  Does this make sense to anybody else?
 
  As long as an extension can be marked as both, then this certainly sounds like
  a fine idea.

 Aren't PECL package version numbers already providing this?

But not everything is in PECL :)

Derick

-- 
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Learning from Python: PEPping the PHP Development Process

2004-08-27 Thread Hartmut Holzgraefe
Derick Rethans wrote:
Aren't PECL package version numbers already providing this?
But not everything is in PECL :)
any bundled extensions that are still EXPERIMENTAL should
move to PECL anyway IMHO
--
Hartmut Holzgraefe  [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


Re: [PHP-DEV] Learning from Python: PEPping the PHP Development Process

2004-08-27 Thread Ilia Alshanetsky
On August 27, 2004 11:31 am, Hartmut Holzgraefe wrote:
 Derick Rethans wrote:
 Aren't PECL package version numbers already providing this?
 
  But not everything is in PECL :)

 any bundled extensions that are still EXPERIMENTAL should
 move to PECL anyway IMHO

+1

Ilia

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Learning from Python: PEPping the PHP Development

2004-08-27 Thread Daniel Convissor
[Oops.  Send this email directly to Rasmus rather than the list...]

On Thu, Aug 26, 2004 at 12:58:21PM -0700, Rasmus Lerdorf wrote:
   2. web app sends it to internals@ or some other relevant list
   3. Replies to that email automatically get picked up by the web app
   4. Alternatively, you can add comments via the web app which would
  also get bounced to the relevant mailing list

nyphp.org is working on something called CLEW, which will be able to
do exactly that.  See the following links for more info:
   http://clew.nyphp.org/clew/clew
   http://nyphp.org/content/presentations/nyphp/index.php?slide=13

--Dan

-- 
 T H E   A N A L Y S I S   A N D   S O L U T I O N S   C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
 4015 7th Ave #4, Brooklyn NY 11232  v: 718-854-0335 f: 718-854-0409

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Learning from Python: PEPping the PHP Development Process

2004-08-27 Thread Zeev Suraski
At 18:33 27/08/2004, Ilia Alshanetsky wrote:
On August 27, 2004 11:31 am, Hartmut Holzgraefe wrote:
 Derick Rethans wrote:
 Aren't PECL package version numbers already providing this?
 
  But not everything is in PECL :)

 any bundled extensions that are still EXPERIMENTAL should
 move to PECL anyway IMHO
+1
-1.
I think that only extensions whose API is subject to change should be 
'banned' from being a part of the standard release.  Core extensions, with 
stable APIs, that just didn't get enough testing (e.g. SOAP, DOM or XSL, at 
least I think that's the case) can  should stay bundled IMHO.

Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


Re: [PHP-DEV] Learning from Python: PEPping the PHP Development Process

2004-08-27 Thread Christian Stocker

On 27.8.2004 20:23 Uhr, Zeev Suraski wrote:
At 18:33 27/08/2004, Ilia Alshanetsky wrote:
On August 27, 2004 11:31 am, Hartmut Holzgraefe wrote:
 Derick Rethans wrote:
 Aren't PECL package version numbers already providing this?
 
  But not everything is in PECL :)

 any bundled extensions that are still EXPERIMENTAL should
 move to PECL anyway IMHO
+1

-1.
I think that only extensions whose API is subject to change should be 
'banned' from being a part of the standard release.  Core extensions, 
with stable APIs, that just didn't get enough testing (e.g. SOAP, DOM or 
XSL, at least I think that's the case) can  should stay bundled IMHO.
I knew it, that this will stay in the head of people ;) XSL and DOM are 
not experimental anymore (as already mentioned in another mail in the 
infamous flame thread yesterday).

We forgot to remove the EXPERIMENTAL file in CVS, but did that recently. 
It was always intented to marked as stable for 5.0.0. There's no API to 
change anyway, as long as the w3c doesn't change it, at least ;)

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  |  [EMAIL PROTECTED]  |  gnupg-keyid 0x5CE1DECB
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


Re: [PHP-DEV] Learning from Python: PEPping the PHP Development Process

2004-08-26 Thread Rasmus Lerdorf
On Thu, 26 Aug 2004, Sebastian Bergmann 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).

-Rasmus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Learning from Python: PEPping the PHP Development Process

2004-08-26 Thread Sebastian Bergmann
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/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


Re: [PHP-DEV] Learning from Python: PEPping the PHP Development Process

2004-08-26 Thread Sterling Hughes
Rasmus Lerdorf wrote:
On Thu, 26 Aug 2004, Sebastian Bergmann 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


Re: [PHP-DEV] Learning from Python: PEPping the PHP Development

2004-08-26 Thread Rasmus Lerdorf
Just to clarify, I didn't propose taking the PEAR PEPr system verbatim.
To be honest, I have never really used it, beyond skimming through things
because it is handy that everything is in one place.  I don't find our
feature/change request category in the bugs database to be all that
effective.  Things tend to get lost in the noise there.

I am not sure it would be effective, but I think it might be worth a try
to have a single place for people to propose features and changes and to
have an organized record of decisions surrounding these proposals.  At the
same time I absolutely hate using a web system for discussing things, so
such a system should have an email gateway.

As in:

  1. Submit proposal to web app
  2. web app sends it to internals@ or some other relevant list
  3. Replies to that email automatically get picked up by the web app
  4. Alternatively, you can add comments via the web app which would
 also get bounced to the relevant mailing list

-Rasmus


On Thu, 26 Aug 2004, Andi Gutmans wrote:

 It might be nice to have this documentation in place for people to
 reference and for discussions (and most importantly to look back at for
 understanding design decisions). It also would make it easier for people to
 propose new features or changes in PHP.
 This doesn't necessarily have to do with voting. In general, the PHP
 project up to now has worked pretty well in this sense. Like in most
 open-source projects the maintainer of a certain piece of PHP usually has
 more say than others (and thank god we have many maintainers and not an
 individual person for the whole thing). That doesn't mean that overwhelming
 popular demand hasn't had it affects either. I think it's a balance which
 can only be reached by cooperation.

 Andi

 At 02:06 PM 8/26/2004 -0400, Greg Beaver wrote:
 Rasmus Lerdorf wrote:
 
 On Thu, 26 Aug 2004, Sebastian Bergmann 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
 
 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP-DEV] [TAG: Process Improvement] Re: [PHP-DEV] Learning from Python: PEPping the PHP Development

2004-08-26 Thread Sterling Hughes
Rasmus Lerdorf wrote:
Just to clarify, I didn't propose taking the PEAR PEPr system verbatim.
To be honest, I have never really used it, beyond skimming through things
because it is handy that everything is in one place.  I don't find our
feature/change request category in the bugs database to be all that
effective.  Things tend to get lost in the noise there.
I am not sure it would be effective, but I think it might be worth a try
to have a single place for people to propose features and changes and to
have an organized record of decisions surrounding these proposals.  At the
same time I absolutely hate using a web system for discussing things, so
such a system should have an email gateway.
As in:
 1. Submit proposal to web app
 2. web app sends it to internals@ or some other relevant list
 3. Replies to that email automatically get picked up by the web app
 4. Alternatively, you can add comments via the web app which would
also get bounced to the relevant mailing list
 

One thing we could do is have a TAG message in our existing lists, 
when a discussion like this one becomes noteworthy, someone could 
respond with a subject [TAG: Feature Request] and that would propagate 
the conversation to the necessary portion of the web app?

-Sterling
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


Re: [PHP-DEV] Learning from Python: PEPping the PHP Development

2004-08-26 Thread Sebastian Bergmann
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/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


Re: [PHP-DEV] Learning from Python: PEPping the PHP Development

2004-08-26 Thread Sebastian Bergmann
Rasmus Lerdorf wrote:
1. Submit proposal to web app
2. web app sends it to internals@ or some other relevant list
3. Replies to that email automatically get picked up by the web app
4. Alternatively, you can add comments via the web app which would
   also get bounced to the relevant mailing list
 Then again, why use a webapp at all? AFAICS, Python uses a special
 directory in CVS [1] to which the PEPs are added.
 I think there is a certain beauty to this low-tech approach as you
 get access control and history out-of-the-box from CVS. And through the
 CVS commit mails one can easily follow the process via mail.
 --
 [1] http://cvs.sf.net/viewcvs.py/python/python/nondist/peps/
--
Sebastian Bergmann
http://sebastian-bergmann.de/   http://phpOpenTracker.de/
Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php