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
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
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
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
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/
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/
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
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
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
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.
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
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
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
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
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
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
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
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
[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
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
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
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]
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
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
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.
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
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
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
28 matches
Mail list logo
