Re: [PHP-DEV] Setting up RFC

[jeroen]

There are some doubts on it, but because:

Zak Greant:
> (...) I don't
> see how it could hurt to try. :)

And the main advantage is:
> I just want a way to more
> easily keep track of what is going on. :)

In fact, it is not so different from discussion on php-dev (it's only an
addition, only important pieces and new opinions are selected to come into
the RFC (the updating I was talking about - IMO extremely important -
without that, it's better to not start with it)).
An RFC can and should start out as very small&simple, just like an email :-)

The fact they are numbered and stored easily, not mixed up with off-topic
discussion like Zend Licencing issues ;-), eases the discussion IMO, and
prevents endless repetetion of the same arguments.


So, I think it should be given try, to start with, create a CVS module
php-rfc, and add come rules there? Voting etc can be either implemented
later (there's no hurry), or will be held the old way: by mail on php-dev.


Regards,
Jeroen



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Setting up RFC

[Stig Sæther Bakken]

[Sterling Hughes <[EMAIL PROTECTED]>]
> On Wed, 15 Aug 2001, Zeev Suraski wrote:
> 
> > At 10:23 15-08-01, Stig Sæther Bakken wrote:
> > >[Hi,
> > >
> > >I think one of the problems with this is that even if php-dev comes up
> > >with a system for determining which feature it wants to see in PHP, we
> > >still depend on Zeev, Andi or someone else @ Zend to implement them.
> > >An RFC system would be a support for Zend's decision-making.  At the
> > >end of the day, due to the licensing issues, php-dev is not the body
> > >governing the language, it has an advisory role only.
> >
> > Generally, I agree with you, except it's not because of licensing issues
> > (will we end up with a load of features suddenly getting into PHP if/when
> > the engine license changes?).  Many other projects behave that way.  With a
> > language definition, "vox populi, vox Dei" doesn't tend to work very well.
> >
> 
> Yes, the difference is, this creates a situation where the PHP
> Development team does not have control of the core language,
> Zend Technologies Ltd.  does.  Whether this is a issue with a
> basis in principle or a basis in practicality is up to debate,
> however, the problem remains.
> 
> Zend having control of the language has nothing to do with "vox
> Populi, vox Dei" (translated "the voice of the People, the voice
> of the Gods"), its more of a matter of *who* has control -- Zend
> Technologies or the PHP Developers.

Historical note: we had, ahem, "feature discussions" in 3.0 before
Zend existed, so it doesn't have only to do with the fact that Zend is
a commercial company.

An important issue here is that for us, "control of the language" also
means writing code.  Granted, there's reduced motivation for people
willing to dive into the Zend code, since their contributions would
become the property of Zend, but so far Andi & Zeev are probably the
only members of the community who understand the code well enough to
implement stuff like ticks and namespaces.  So there's really no point
in broadening the control of the language until Zend has a license
that makes people like Sascha willing to put a lot of their time into
the Zend code.

Kristian thinks a dual GPL/QPL license would be a good idea for Zend
(it apparently works for Troll Tech), but that's _definitely_ for
another thread.

 - Stig

-- 
  Stig Sæther Bakken <[EMAIL PROTECTED]>
  Fast Search & Transfer ASA, Trondheim, Norway

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Setting up RFC

[Zeev Suraski]

At 21:24 15-08-01, Sterling Hughes wrote:
> Oh - I see! So the "Zend" on the License is really just shorthand for
> "Zeev and Andi", has nothing to do with Zend Technologies Ltd.  Good
> to know. ;))

In practice, pretty much, yes.  I don't remember Doron's, Adi's or Daniel's 
last contributions :)

> As I said -- this may have no basis in practicality -- I think it
> does to some extent, otherwise you wouldn't hear this many
> reasonable (but sometimes passionate) people complaining.  Still,
> taking your assumption that the license and Zend's control of it is
> meaningless, why not go ahead and change the license today?  If it
> means nothing, why are you with a license that causes such strife in
> the PHP community?

A small part in the PHP developer community, mind you.  As I told Stig, it 
is what you make of it - practically, it's nothing.

>   If you'd like, I'll go setup a sourceforge project for
> the Zend engine today!

I don't want to see the engine as a sourceforge project today, tomorrow, or 
anytime in the future, thank you very much :)

As I said in LinuxTag, the license issue was blown out of proportion 
completely.  It has no practical meaning for any PHP user or 
developer.  Changing the license only means that we will no longer be able 
to re-license the engine to other companies who make commercial use of 
it.  So basically, changing it means a loss of a source of possible income 
for Zend, while giving the PHP community nothing (MySQL AB *lives* from 
that source of income exactly).  Perception wise, it might make the world 
much more rosy.  To be bluntly honest, I seriously doubt it (we're not in a 
bad shape today, plus I have every reason to believe that things won't 
change radically if&when we change the license).  As far as Zend is 
perceived, much like the license issue was a non issue until some made it 
an issue, I fear that once it's gone, there'll be something else to replace 
it.  When you don't like somebody or something, you can find whatever suite 
of 'objective' reasons to back you up.

Zeev


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Setting up RFC

[Sterling Hughes]

On Wed, 15 Aug 2001, Zeev Suraski wrote:

> At 12:15 15-08-01, Sterling Hughes wrote:
> >On Wed, 15 Aug 2001, Zeev Suraski wrote:
> >
> > > At 10:23 15-08-01, Stig Sæther Bakken wrote:
> > > >[Hi,
> > > >
> > > >I think one of the problems with this is that even if php-dev comes up
> > > >with a system for determining which feature it wants to see in PHP, we
> > > >still depend on Zeev, Andi or someone else @ Zend to implement them.
> > > >An RFC system would be a support for Zend's decision-making.  At the
> > > >end of the day, due to the licensing issues, php-dev is not the body
> > > >governing the language, it has an advisory role only.
> > >
> > > Generally, I agree with you, except it's not because of licensing issues
> > > (will we end up with a load of features suddenly getting into PHP if/when
> > > the engine license changes?).  Many other projects behave that way.  With a
> > > language definition, "vox populi, vox Dei" doesn't tend to work very well.
> > >
> >
> > Yes, the difference is, this creates a situation where the PHP
> > Development
> > team does not have control of the core language, Zend Technologies Ltd.
> > does.  Whether this is a issue with a basis in principle or a basis in
> > practicality is up to debate, however, the problem remains.
>
> Sterling, that's bull - popular perhaps - but still, bull.  Zend as a
> commercial entity doesn't decide on PHP's features.  Nobody in Zend has
> control over the language just because he's a Zend employee.  Other Zend
> employees participate in the discussions just like the rest of you, and
> often make quite constructive remarks, just like the rest.  However, it's
> not as if Zend employees can muck around the language, whereas php-dev can
> just stand on the side watching.
> We all like to look up at corporations, blame them for the problems and
> rebel.  It's basic human nature.  It just has very little to do with
> reality in this case.  Nothing, in practice, except for that license
> everybody enjoys bashing (and I claim again and again, that it won't make a
> radical change if it changes, except for perception).
> Andi and myself regulate the engine, on a personal basis, since 1997, and
> it has nothing to do with Zend (which was founded towards the end of
> 1999).  Between us, as a commercial entity, nobody could care less whether
> there are advices, namespaces or how exactly the object model would look
> like.  That's why the situation wouldn't change radically if/when the
> engine license changes, much like it wasn't any different *before* the
> engine license was even introduced, in the PHP 3.0 days.  Having regulators
> over the 'kernel' of the project is certainly not very unique to the PHP,
> and had a significant role in bringing PHP to where it is today, and not
> where Perl is today, for example.
>

Oh - I see! So the "Zend" on the License is really just shorthand for
"Zeev and Andi", has nothing to do with Zend Technologies Ltd.  Good
to know. ;))

As I said -- this may have no basis in practicality -- I think it
does to some extent, otherwise you wouldn't hear this many
reasonable (but sometimes passionate) people complaining.  Still,
taking your assumption that the license and Zend's control of it is
meaningless, why not go ahead and change the license today?  If it
means nothing, why are you with a license that causes such strife in
the PHP community?  If you'd like, I'll go setup a sourceforge project for
the Zend engine today!

-Sterling


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Setting up RFC

[Daniel Beckham]

Everyone loves to hate Perl don't they?

Daniel

- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: "Andrei Zmievski" <[EMAIL PROTECTED]>; "Zeev Suraski" <[EMAIL PROTECTED]>;
"Sterling Hughes" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
"Sæther Bakken @gecadsoftware.com" <[EMAIL PROTECTED]>
Sent: Wednesday, August 15, 2001 10:43 AM
Subject: Re: [PHP-DEV] Setting up RFC


> Hi Andrei!
> On Wed, 15 Aug 2001, Andrei Zmievski wrote:
>
> > On Wed, 15 Aug 2001, Zeev Suraski wrote:
> > > like.  That's why the situation wouldn't change radically if/when the
> > > engine license changes, much like it wasn't any different *before* the
> > > engine license was even introduced, in the PHP 3.0 days.  Having
regulators
> > > over the 'kernel' of the project is certainly not very unique to the
PHP,
> > > and had a significant role in bringing PHP to where it is today, and
not
> > > where Perl is today, for example.
> >
> > You always compare PHP to Perl. How about Python? It's a well designed
> > language that's pretty open for development.. Look at their PEPs system.
> >
> maybe cause PHP it's better than Perl but not than Python? :)
>
> -- teodor
>
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Setting up RFC

[teo]

Hi Andrei!
On Wed, 15 Aug 2001, Andrei Zmievski wrote:

> On Wed, 15 Aug 2001, Zeev Suraski wrote:
> > like.  That's why the situation wouldn't change radically if/when the 
> > engine license changes, much like it wasn't any different *before* the 
> > engine license was even introduced, in the PHP 3.0 days.  Having regulators 
> > over the 'kernel' of the project is certainly not very unique to the PHP, 
> > and had a significant role in bringing PHP to where it is today, and not 
> > where Perl is today, for example.
> 
> You always compare PHP to Perl. How about Python? It's a well designed
> language that's pretty open for development.. Look at their PEPs system.
> 
maybe cause PHP it's better than Perl but not than Python? :)

-- teodor

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Setting up RFC

[Zeev Suraski]

At 18:13 15-08-01, Andrei Zmievski wrote:
>On Wed, 15 Aug 2001, Zeev Suraski wrote:
> > like.  That's why the situation wouldn't change radically if/when the
> > engine license changes, much like it wasn't any different *before* the
> > engine license was even introduced, in the PHP 3.0 days.  Having 
> regulators
> > over the 'kernel' of the project is certainly not very unique to the PHP,
> > and had a significant role in bringing PHP to where it is today, and not
> > where Perl is today, for example.
>
>You always compare PHP to Perl. How about Python? It's a well designed
>language that's pretty open for development.. Look at their PEPs system.

And you always compare to Python :)  I try to compare apples and apples.  I 
don't see Python as an equivalent of PHP, whereas I do see Perl as 
something that had to potential to be a good thing, and blew it.  There are 
also many other, non-language examples, of opensource projects that work in 
the same way.

Zeev


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Setting up RFC

[Andrei Zmievski]

On Wed, 15 Aug 2001, Zeev Suraski wrote:
> like.  That's why the situation wouldn't change radically if/when the 
> engine license changes, much like it wasn't any different *before* the 
> engine license was even introduced, in the PHP 3.0 days.  Having regulators 
> over the 'kernel' of the project is certainly not very unique to the PHP, 
> and had a significant role in bringing PHP to where it is today, and not 
> where Perl is today, for example.

You always compare PHP to Perl. How about Python? It's a well designed
language that's pretty open for development.. Look at their PEPs system.

-Andrei

"In this age, which believes that there is a short cut to everything,
 the greatest lesson to be learned is that the most difficult way is, in
 the long run, the easiest."
-Henry Miller, The Books in My Life

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Setting up RFC

[Zeev Suraski]

At 12:15 15-08-01, Sterling Hughes wrote:
>On Wed, 15 Aug 2001, Zeev Suraski wrote:
>
> > At 10:23 15-08-01, Stig Sæther Bakken wrote:
> > >[Hi,
> > >
> > >I think one of the problems with this is that even if php-dev comes up
> > >with a system for determining which feature it wants to see in PHP, we
> > >still depend on Zeev, Andi or someone else @ Zend to implement them.
> > >An RFC system would be a support for Zend's decision-making.  At the
> > >end of the day, due to the licensing issues, php-dev is not the body
> > >governing the language, it has an advisory role only.
> >
> > Generally, I agree with you, except it's not because of licensing issues
> > (will we end up with a load of features suddenly getting into PHP if/when
> > the engine license changes?).  Many other projects behave that way.  With a
> > language definition, "vox populi, vox Dei" doesn't tend to work very well.
> >
>
> Yes, the difference is, this creates a situation where the PHP 
> Development
> team does not have control of the core language, Zend Technologies Ltd.
> does.  Whether this is a issue with a basis in principle or a basis in
> practicality is up to debate, however, the problem remains.

Sterling, that's bull - popular perhaps - but still, bull.  Zend as a 
commercial entity doesn't decide on PHP's features.  Nobody in Zend has 
control over the language just because he's a Zend employee.  Other Zend 
employees participate in the discussions just like the rest of you, and 
often make quite constructive remarks, just like the rest.  However, it's 
not as if Zend employees can muck around the language, whereas php-dev can 
just stand on the side watching.
We all like to look up at corporations, blame them for the problems and 
rebel.  It's basic human nature.  It just has very little to do with 
reality in this case.  Nothing, in practice, except for that license 
everybody enjoys bashing (and I claim again and again, that it won't make a 
radical change if it changes, except for perception).
Andi and myself regulate the engine, on a personal basis, since 1997, and 
it has nothing to do with Zend (which was founded towards the end of 
1999).  Between us, as a commercial entity, nobody could care less whether 
there are advices, namespaces or how exactly the object model would look 
like.  That's why the situation wouldn't change radically if/when the 
engine license changes, much like it wasn't any different *before* the 
engine license was even introduced, in the PHP 3.0 days.  Having regulators 
over the 'kernel' of the project is certainly not very unique to the PHP, 
and had a significant role in bringing PHP to where it is today, and not 
where Perl is today, for example.

Zeev


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Setting up RFC

[Sterling Hughes]

On Wed, 15 Aug 2001, Zeev Suraski wrote:

> At 10:23 15-08-01, Stig Sæther Bakken wrote:
> >[Hi,
> >
> >I think one of the problems with this is that even if php-dev comes up
> >with a system for determining which feature it wants to see in PHP, we
> >still depend on Zeev, Andi or someone else @ Zend to implement them.
> >An RFC system would be a support for Zend's decision-making.  At the
> >end of the day, due to the licensing issues, php-dev is not the body
> >governing the language, it has an advisory role only.
>
> Generally, I agree with you, except it's not because of licensing issues
> (will we end up with a load of features suddenly getting into PHP if/when
> the engine license changes?).  Many other projects behave that way.  With a
> language definition, "vox populi, vox Dei" doesn't tend to work very well.
>

Yes, the difference is, this creates a situation where the PHP Development
team does not have control of the core language, Zend Technologies Ltd.
does.  Whether this is a issue with a basis in principle or a basis in
practicality is up to debate, however, the problem remains.

Zend having control of the language has nothing to do with "vox
Populi, vox Dei" (translated "the voice of the People, the voice of
the Gods"), its more of a matter of *who* has control -- Zend
Technologies or the PHP Developers.

And tell me, what other languages have a commercial body controlling
the evolution?  Certainly not any that I know of.  Yes, they may
have a person, or a small group of people deciding what goes in the
language and what doesn't, however, this differs in three manners:

1) The leaders are "elected" by the community -- this makes it
so there are signifigantly fewer power struggles (or dick size
wars to use a Zak term).

2) This small group usually consists of all the core developers,
not just two.

3) The leaders are not a commercial company.

The relationship between a commercial company and a group of open
source developers is a delicate thing, which requires work to
maintain and foster, the feeling in the community, that I am picking up
is that Zend has dropped the ball -- the licensing issues, and some
of the commercial products surrounding the Zend engine have created in
many a feeling of alienation, and that Zend is exploiting its position
as the creator of the Zend engine to corner the PHP market.

While this does not bode well for either side -- I don't think that
means the relationship cannot be repaired, however, I do think that
a couple of things do need to happen in order for the relationship
to continue with any level of civility.

1) The Zend Engine should be moved to a separate project,
outside of the exclusive control of Zend Technologies Ltd., under a
BSD (or some other, more friendly license, ie, Apache or MIT).  The
PHP project should be able to have control of this engine with
the same, or greater voice than Zend..

2) The communication between Zend & PHP with relation to
internal Zend developments that effect the future of PHP should
be improved.  PHP 3.1 is a perfect example of a breakdown in
communication.

3) (I think this'd be nice) Developments that Zend makes -- such
as the Zend optimizer -- that make technical sense to be
natively supported in the engine, should be added.  A good
candidate for this would be the Zend Optimizer.  Zend can still
make a business around PHP -- however it shouldn't be in forms
that detract from the average programmers ability to make use of
PHP (Zend IDE, Zend Debugger and Zend Launchpad are steps in the
right direction, imho).

Perhaps what I'm saying sounds a bit radical, but I do believe that
Zend & PHP can co-exist with some level of harmony, but changes do
need to me made, and communication needs to occur where people on
both sides listen to each others concerns.

-Sterling

"Any man is liable to error, but only a fool persists in error."
-Cicero (Since we're doing the whole latin thing :)



--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Setting up RFC

[Zeev Suraski]

At 10:23 15-08-01, Stig Sæther Bakken wrote:
>[Hi,
>
>I think one of the problems with this is that even if php-dev comes up
>with a system for determining which feature it wants to see in PHP, we
>still depend on Zeev, Andi or someone else @ Zend to implement them.
>An RFC system would be a support for Zend's decision-making.  At the
>end of the day, due to the licensing issues, php-dev is not the body
>governing the language, it has an advisory role only.

Generally, I agree with you, except it's not because of licensing issues 
(will we end up with a load of features suddenly getting into PHP if/when 
the engine license changes?).  Many other projects behave that way.  With a 
language definition, "vox populi, vox Dei" doesn't tend to work very well.

Zeev


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Setting up RFC

[Stig Sæther Bakken]

["Jeroen van Wolffelaar" <[EMAIL PROTECTED]>]
> Hi,
> 
> About a month ago there was a discussion on the Engine 2 mailing list, about
> a possible RFC-proces for the more imporant PHP-issues. In the end, there
> was some consensus that it would be good if such a system exists.
> 
> I'm simply writing to get some comments, to hear what the general opinion
> is. If that is not negative, I think it should be tried to set it up.
> 
> 
> About the details, there needs to be discussion of course, but it would be
> more efficient to discuss those things after a proposal has been made, in
> stead of construct such a proposal by discussion.
> 
> Joey Smith and Zak Great supported the idea on the list, but the discussion
> went dead. Below I quote some of their mails.

Hi,

I think one of the problems with this is that even if php-dev comes up
with a system for determining which feature it wants to see in PHP, we
still depend on Zeev, Andi or someone else @ Zend to implement them.
An RFC system would be a support for Zend's decision-making.  At the
end of the day, due to the licensing issues, php-dev is not the body
governing the language, it has an advisory role only.

 - Stig

-- 
  Stig Sæther Bakken <[EMAIL PROTECTED]>
  Fast Search & Transfer ASA, Trondheim, Norway

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Setting up RFC

[derick]

On Tue, 14 Aug 2001, John Donagher wrote:

> With what end in mind is an RFC to be created for? In the IETF, RFC's are
> typically long, complex, and authoritative. They are often referenced for years
> after their inception. Do you honestly think we could (or want to) achieve this
> with PHP feature RFC's? Or will they be used only before initial feature
> implementation, then quickly outdated and discarded? That is my biggest problem
> with documents: they take a lot of effort to create, are often difficult to
> grok, and _almost always_ have a very short lifecycle.

Although probable PHP RFC's won't be as complex as IETF RFC's, I still
think the main problem is that almost every developer hates it to write
docs. Doc writing is the most worse thing of software developing, I think
most people will agree with me on this.

However I think the whole RFC will lurk up too much of our precious time.
The idea may be good, but I don't think it will work out as it is intended
to be.

regards,

Derick Rethans

-
PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
 SRM: Site Resource Manager - www.vl-srm.net
-


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Setting up RFC

[Zak Greant]

Jim wrote:
> Zak Greant <[EMAIL PROTECTED]> wrote:
> > :) I should have chosen the symbols more carefully. 
> > They seem to have generated more comments than the original proposal...
> > 
> > Does anyone have any comments pertaining to the *concept*? :)
> 
> i was trying to drive at the point that you've just restated a
> slightly weaker form of the apache project guidelines.

Not quite. I was just describing a tool to help in browsing
the accumulated opinions.

> (now, a tool to make it easier to implement those guidelines may be a
> good idea. but i see that as distinct from the process itself. and i
> think anything that moves discussion out of email is doomed to fail.)

Possibly... given how many discussions fail (or are doomed to some
sort of unlife - like the function renaming discussion) I don't
see how it could hurt to try. :)
 
> the real problem is determining who gets to vote.

I am not even worried about votes, etc. I just want a way to more
easily keep track of what is going on. :)

The rating were just there to provide a quick way to track general
opinion.

--zak


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Setting up RFC

[jimw]

Zak Greant <[EMAIL PROTECTED]> wrote:
> :) I should have chosen the symbols more carefully. 
> They seem to have generated more comments than the original proposal...
> 
> Does anyone have any comments pertaining to the *concept*? :)

i was trying to drive at the point that you've just restated a
slightly weaker form of the apache project guidelines.

(now, a tool to make it easier to implement those guidelines may be a
good idea. but i see that as distinct from the process itself. and i
think anything that moves discussion out of email is doomed to fail.)

the real problem is determining who gets to vote.

jim

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Setting up RFC

[Zak Greant]

:) I should have chosen the symbols more carefully. 
They seem to have generated more comments than the original proposal...

Does anyone have any comments pertaining to the *concept*? :)

--zak

- Original Message - 
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, August 14, 2001 9:05 PM
Subject: Re: [PHP-DEV] Setting up RFC


> Sterling Hughes <[EMAIL PROTECTED]> wrote:
> >Actually, (+-) 0 are really terms and votes, in other projects I've
> >been involved in, there interpreted as "I don't like it, but I won't
> >stop you" and "I like it, but its not something I think is
> >absolutely necessary"
> 
> right.
> 
> http://dev.apache.org/guidelines.html is probably worth reading for
> folks not familiar with the apache project's process.
> 
> this presentation is worth checking out, too:
> 
>   http://www.ics.uci.edu/~fielding/talks/apache98/index.htm
> 
> jim
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
> 


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Setting up RFC

[jimw]

Sterling Hughes <[EMAIL PROTECTED]> wrote:
>Actually, (+-) 0 are really terms and votes, in other projects I've
>been involved in, there interpreted as "I don't like it, but I won't
>stop you" and "I like it, but its not something I think is
>absolutely necessary"

right.

http://dev.apache.org/guidelines.html is probably worth reading for
folks not familiar with the apache project's process.

this presentation is worth checking out, too:

  http://www.ics.uci.edu/~fielding/talks/apache98/index.htm

jim

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Setting up RFC

[Sterling Hughes]

On Tue, 14 Aug 2001, Zak Greant wrote:

> Joey wrote:
> > > Are you doing a new O'Reilly book, PHP-DEV in a nutshell?
>
> Subtitled: A Rogues Gallery ;)
>
> > > -Sterling
> >
> > I especially enjoy the idea of "positive zero" and "negative
> > zero". :)
>
> I think that +/-0 would accurately portray the sometimes
> odd nature of support for proposals. ;)
>
> --zak


Actually, (+-) 0 are really terms and votes, in other projects I've
been involved in, there interpreted as "I don't like it, but I won't
stop you" and "I like it, but its not something I think is
absolutely necessary"

Sort of the concept of either abstaining -- or abstaining with an
objection.

-Sterling


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Setting up RFC

[Zak Greant]

Joey wrote:
> > Are you doing a new O'Reilly book, PHP-DEV in a nutshell?

Subtitled: A Rogues Gallery ;)

> > -Sterling
> 
> I especially enjoy the idea of "positive zero" and "negative
> zero". :)

I think that +/-0 would accurately portray the sometimes
odd nature of support for proposals. ;)

--zak


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Setting up RFC

[Joey Smith]

> > +1: Strongly Support
> > +0: Support
> >  0: Neutral
> > -0: Oppose
> > -1: Strongly Oppose
> 
> Are you doing a new O'Reilly book, PHP-DEV in a nutshell?
> 
> -Sterling

I especially enjoy the idea of "positive zero" and "negative
zero". :)


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Setting up RFC

[Sterling Hughes]

> Proposal: Foo*
> --
> ...
> Rasmus +0This should help fix issue x and bug y.
> Richard -
> Sascha +0This proposal supports RFC 10921 in a good way.
> Sterling   -0RFC 10921 is kind of strange.
> Torben -1There is already too much foo in the language.
> Zak+1Proposal foo must be obeyed
> Zeev   -0We don't need foo, we can just modify bar.
>

:)

> * "The characters and opinions portrayed and the names used herein are
> fictitious and any
> resemblance to the names, character, or history of any person is
> coincidental and unintentional!" ;)
>
> +1: Strongly Support
> +0: Support
>  0: Neutral
> -0: Oppose
> -1: Strongly Oppose

Are you doing a new O'Reilly book, PHP-DEV in a nutshell?

-Sterling



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Setting up RFC

[Zak Greant]

Jeroen wrote:
> They should _not_ be too technical, _not_ too long, but yet as simple as
> possible, but exactly as precise enough to be relatively unambigious if
you
> know about the PHP conventions. For example like that zend engine 2 white
> paper.
>
> But they need to be updated, and not discarded.
>
> They shouldn't be too hard to create, and definitely not too hard to grok.
A
> simple template could help achieving this.
>
> All of the above IMHO,

I think that the most basic problems that we encounter are:

The information from a given discussion becomes more and more
difficult to access as time passes.

We perform additional work due to the above problem.

If we can have a simple system that is easy to browse and use for
discussing
these issues, I think that would be perfect...

The system would work something like this:

Each person has an account in the system.
Someone makes a proposal.

i.e.

Proposal: Foo
-
Incorporate feature foo into the Zend engine.

Abstract

The foo feature would do bar and baz.

Details
---
...

Other developers would respond to the proposal.

All interested developers could discuss the issue on a mailing list or
threaded forum - however all interested developer would have to simply
and
explicitly state their current position on their account.

i.e.

Zak Greant

Proposal Foo

Position: [x] Strongly Support
  [ ] Support
  [ ] Neutral
  [ ] Oppose
  [ ] Strongly Oppose

Position statement (one or two sentences)
[ I believe that foo would elegantly solve problem x, while
remaining
  true to the PHP idiom ]


A status page would report on the proposals and positions of the various
people:


Something like:
[--- choose a proposal --][+]

Once a proposal had been chosen, you would see a list like:

Proposal: Foo*
--
...
Rasmus +0This should help fix issue x and bug y.
Richard -
Sascha +0This proposal supports RFC 10921 in a good way.
Sterling   -0RFC 10921 is kind of strange.
Torben -1There is already too much foo in the language.
Zak+1Proposal foo must be obeyed
Zeev   -0We don't need foo, we can just modify bar.

* "The characters and opinions portrayed and the names used herein are
fictitious and any
resemblance to the names, character, or history of any person is
coincidental and unintentional!" ;)

+1: Strongly Support
+0: Support
 0: Neutral
-0: Oppose
-1: Strongly Oppose

 -: Have not commented


We would still be able to have good, detailed discussions without being
too formal
or losing data. We could easily see what was going on with a discussion
without having
to dig through %$^&-loads of email. Plus everything would be archived
for future ref.

For really important stuff, we can do an RFC after the discussion.

--zak





-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Setting up RFC

[Joey Smith]

On Tue, 14 Aug 2001, John Donagher wrote the following to [EMAIL PROTECTED]:
> With what end in mind is an RFC to be created for? In the IETF, RFC's are
> typically long, complex, and authoritative. They are often referenced for years
> after their inception. Do you honestly think we could (or want to) achieve this
> with PHP feature RFC's? Or will they be used only before initial feature
> implementation, then quickly outdated and discarded? That is my biggest problem
> with documents: they take a lot of effort to create, are often difficult to
> grok, and _almost always_ have a very short lifecycle.

PHP feature RFC != IETF RFC's.

Go back and read my original proposal on the issue. What I had in mind
was something more like what Perl has done with the Perl 6 RFC's, or
(perhaps) the PEP's of Python...

The point being that there is a LOT of discussion on certain topics, and
people often change sides on an issue over the life of the discussion. I
was simply trying to say "Let's make this a *bit* more orderly.", mainly
becuase I had already lost track of several of the then-current threads
on the zend-engine list.


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Setting up RFC

[Jeroen van Wolffelaar]

> With what end in mind is an RFC to be created for? In the IETF, RFC's are
> typically long, complex, and authoritative. They are often referenced for
years
> after their inception.
> Do you honestly think we could (or want to) achieve this
> with PHP feature RFC's? Or will they be used only before initial feature
> implementation, then quickly outdated and discarded? That is my biggest
problem
> with documents: they take a lot of effort to create, are often difficult
to
> grok, and _almost always_ have a very short lifecycle.

They should _not_ be too technical, _not_ too long, but yet as simple as
possible, but exactly as precise enough to be relatively unambigious if you
know about the PHP conventions. For example like that zend engine 2 white
paper.

But they need to be updated, and not discarded.

They shouldn't be too hard to create, and definitely not too hard to grok. A
simple template could help achieving this.

All of the above IMHO,

Jeroen



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Setting up RFC

[John Donagher]

On Wed, 15 Aug 2001, James Moore wrote:

> 
> RFC.. Request For Comments, its as simple as that someone posts a document
> outlining what they want changed/want to do, calls it an RFC and is
> litterally making a request for comments on their idea. I think this is a
> good idea for large things but if we encourage too much we will suddenly be
> flooded with RFC's all over the place then they begin to conflict.. I think
> that if someone feels somthing is really important then an RFC is a good
> idea but I certainly dont want a couple a week to plough through.
> 

With what end in mind is an RFC to be created for? In the IETF, RFC's are
typically long, complex, and authoritative. They are often referenced for years
after their inception. Do you honestly think we could (or want to) achieve this
with PHP feature RFC's? Or will they be used only before initial feature
implementation, then quickly outdated and discarded? That is my biggest problem
with documents: they take a lot of effort to create, are often difficult to
grok, and _almost always_ have a very short lifecycle.

-- 

John Donagher
Application Engineer, Intacct Corp.

Public key available off http://www.keyserver.net
Key fingerprint = 4024 DF50 56EE 19A3 258A  D628 22DE AD56 EEBE 8DDD


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Setting up RFC

[Jeroen van Wolffelaar]

> > The work on Zend Engine 2 has now started, _without_ a proper definition
> of
> > it. IMHO, that's not the ideal situation, since this could lead to
strange
> > inconsequences, because the precise behaviour is decided during
> > implementation.
>
> Umm what about the white paper that was prepaired before work on Zend
Engine
> 2 started?? http://www.zend.com/engine2/ZendEngine-2.0.pdf

It was some kind of RFC indeed, but not updated as discussion progressed. A
lot of other issues were discussed, but without RFC 'backbone'. There was
also no good infrastructure to have a constructive discussion, a lot of
issues have been discussed quite reasonably, but with quite some open ends.

> > For example bug 10437, which wouldn't have existed if the
> > zend engine was properly defined _before_ it was implemented. But it
> simply
> > was the easiest way to implement it...
>
> Probably the the best way too.. not that Ive read 10437 cause Im currently
> working..

Useless to comment on this if you haven't read the report...

> > As you say, for 'light' changes, no official RFC should be created, it
> isn't
> > necessary, mainly because:
> > > at the moment there is no democratic process in PHP, people
> > > just do what they want
>
> Yes this is part of opensource, people will do what they want to do, If I
> want some feature in PHP Ill program it, the general direction of PHP
should
> be decided by a group of people yes but it gets to a point where everyone
is
> saying we should do it this way, that way or another way and in the end
> nothing gets done, at the moment people see what others are doing and
> question it if necessary, if its their extension then they are free to do
> what they want with it.

I am obviously not used enough to open-source, to feel that... I have some
some resistance to myself to change/add something if it isn't agreed... You
shouldn't try that on a paid closed-source project ;-)...

I think you're definitely right on the 'nothing gets done' part.

> - James



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Setting up RFC

[James Moore]

> The work on Zend Engine 2 has now started, _without_ a proper definition
of
> it. IMHO, that's not the ideal situation, since this could lead to strange
> inconsequences, because the precise behaviour is decided during
> implementation.

Umm what about the white paper that was prepaired before work on Zend Engine
2 started?? http://www.zend.com/engine2/ZendEngine-2.0.pdf

> For example bug 10437, which wouldn't have existed if the
> zend engine was properly defined _before_ it was implemented. But it
simply
> was the easiest way to implement it...

Probably the the best way too.. not that Ive read 10437 cause Im currently
working..

> As you say, for 'light' changes, no official RFC should be created, it
isn't
> necessary, mainly because:
> > at the moment there is no democratic process in PHP, people
> > just do what they want

Yes this is part of opensource, people will do what they want to do, If I
want some feature in PHP Ill program it, the general direction of PHP should
be decided by a group of people yes but it gets to a point where everyone is
saying we should do it this way, that way or another way and in the end
nothing gets done, at the moment people see what others are doing and
question it if necessary, if its their extension then they are free to do
what they want with it.

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Setting up RFC

[Joey Smith]

This is why I sort of dropped the subject. I've been waiting until I have
time to look
into Python's PEP system in depth, and see what it requires. Thanks to Jon
for pointing
it out. :)
- Original Message -
From: "Jon Parise" <[EMAIL PROTECTED]>
To: "Jeroen van Wolffelaar" <[EMAIL PROTECTED]>
Cc: "PHP Developers Mailing List" <[EMAIL PROTECTED]>; "Joey Smith"
<[EMAIL PROTECTED]>; "Zak Greant" <[EMAIL PROTECTED]>
Sent: Tuesday, August 14, 2001 4:58 PM
Subject: Re: [PHP-DEV] Setting up RFC


> On Wed, Aug 15, 2001 at 12:18:06AM +0200, Jeroen van Wolffelaar wrote:
>
> > About a month ago there was a discussion on the Engine 2 mailing list,
about
> > a possible RFC-proces for the more imporant PHP-issues. In the end,
there
> > was some consensus that it would be good if such a system exists.
>
> I thought the idea was sound, too, and suggested we mimic
> Python's PEP (Python Enhancement Proposal) system:
>
> http://python.sourceforge.net/peps/
>
> --
> Jon Parise ([EMAIL PROTECTED])  .  Rochester Inst. of Technology
> http://www.csh.rit.edu/~jon/  :  Computer Science House Member
>
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Setting up RFC

[Jeroen van Wolffelaar]

> > On the other hand, the latter one could be named 'RFC process', since it
> > hasn't yet been defined what the heck it is precisely...
>
> RFC.. Request For Comments, its as simple as that someone posts a document
> outlining what they want changed/want to do, calls it an RFC and is
> litterally making a request for comments on their idea. I think this is a
> good idea for large things but if we encourage too much we will suddenly
be
> flooded with RFC's all over the place then they begin to conflict.. I
think
> that if someone feels somthing is really important then an RFC is a good
> idea but I certainly dont want a couple a week to plough through.

That PEP's seem to work quite well, there needs to be some selection on
it... For example: several supporters before you may even start an
(official) RFC for example.

The work on Zend Engine 2 has now started, _without_ a proper definition of
it. IMHO, that's not the ideal situation, since this could lead to strange
inconsequences, because the precise behaviour is decided during
implementation. For example bug 10437, which wouldn't have existed if the
zend engine was properly defined _before_ it was implemented. But it simply
was the easiest way to implement it...

As you say, for 'light' changes, no official RFC should be created, it isn't
necessary, mainly because:
> at the moment there is no democratic process in PHP, people
> just do what they want


Jeroen



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Setting up RFC

[James Moore]

> On the other hand, the latter one could be named 'RFC process', since it
> hasn't yet been defined what the heck it is precisely...

RFC.. Request For Comments, its as simple as that someone posts a document
outlining what they want changed/want to do, calls it an RFC and is
litterally making a request for comments on their idea. I think this is a
good idea for large things but if we encourage too much we will suddenly be
flooded with RFC's all over the place then they begin to conflict.. I think
that if someone feels somthing is really important then an RFC is a good
idea but I certainly dont want a couple a week to plough through.

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Setting up RFC

[Jeroen van Wolffelaar]

> Just poit them to php-dev and keep bringing it up until there is some
decent
> comment on it, at the moment there is no democratic process in PHP, people
> just do what they want and someone normally knows some part of PHP better
> than anyother, IE if you have a sessions thing speak to sascha (via
> PHP-DEV), a COM thing speak to Frank, Daniel and Zeev via PHP-DEV, an
object
> thing speak to Andrei, Zeev and Andi etc... RFC's are a good idea but as
> soon as they are posted to php-dev they are in the archives and it will be
a
> big pain in the arse putting them in CVS due to the karma thing and people
> who dont have cvs access. php-dev is there so use it, yes we should
> formalise some of the more important discussions but it should all take
> place on php-dev.

Discussion about RFC's would have taken place at php-dev, of course.

For the rest of your arguments, you're right, as long as it goes about minor
issues. But I believe it is not true when it comes to really heavy issues,
such as syntax of private object-vars (just an example).

The question is now, is it worth the effort of a complete RFC process for
that, or would a mere formalization of the important discussions, as you
suggest, do?
On the other hand, the latter one could be named 'RFC process', since it
hasn't yet been defined what the heck it is precisely...

> - James

Jeroen


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Setting up RFC

[Jon Parise]

On Wed, Aug 15, 2001 at 12:18:06AM +0200, Jeroen van Wolffelaar wrote:

> About a month ago there was a discussion on the Engine 2 mailing list, about
> a possible RFC-proces for the more imporant PHP-issues. In the end, there
> was some consensus that it would be good if such a system exists.
 
I thought the idea was sound, too, and suggested we mimic
Python's PEP (Python Enhancement Proposal) system:

http://python.sourceforge.net/peps/

-- 
Jon Parise ([EMAIL PROTECTED])  .  Rochester Inst. of Technology
http://www.csh.rit.edu/~jon/  :  Computer Science House Member

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Setting up RFC

[James Moore]

> > Ive written one or two before, mainly for the release process (I think
its
> > in CVS under README.realease_process or somthing like that). Id suggest
> > people just get on and write them and post them to php-dev where people
> > generally read them and make comments. I dont see what there is to
discuss
> > Jeroen.
>
> There should IMO be a more generalized way for this, indeed, it was my
idea
> to put RFC's in cvs. But no in the php4 module, but in a separate.
>
> Main point is that discussions on phpdev die out quite quickly, and you
> can't say then it's decided. And you can't put each proposal in php4 cvs
> either, release proces is not about PHP itself, but about the proces
around
> it, and it is always 'current', since realeases keep coming out...
>
> Anyway, Zak wrote that, not me. So CC'ing to him.

Just poit them to php-dev and keep bringing it up until there is some decent
comment on it, at the moment there is no democratic process in PHP, people
just do what they want and someone normally knows some part of PHP better
than anyother, IE if you have a sessions thing speak to sascha (via
PHP-DEV), a COM thing speak to Frank, Daniel and Zeev via PHP-DEV, an object
thing speak to Andrei, Zeev and Andi etc... RFC's are a good idea but as
soon as they are posted to php-dev they are in the archives and it will be a
big pain in the arse putting them in CVS due to the karma thing and people
who dont have cvs access. php-dev is there so use it, yes we should
formalise some of the more important discussions but it should all take
place on php-dev.

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Setting up RFC

[Jeroen van Wolffelaar]

Hi,

About a month ago there was a discussion on the Engine 2 mailing list, about
a possible RFC-proces for the more imporant PHP-issues. In the end, there
was some consensus that it would be good if such a system exists.

I'm simply writing to get some comments, to hear what the general opinion
is. If that is not negative, I think it should be tried to set it up.


About the details, there needs to be discussion of course, but it would be
more efficient to discuss those things after a proposal has been made, in
stead of construct such a proposal by discussion.

Joey Smith and Zak Great supported the idea on the list, but the discussion
went dead. Below I quote some of their mails.


Regards,
Jeroen



Joey Smith wrote:
> Actually, I felt that the Perl 6 design process had a fairly good idea
> that was poorly implemented...that of RFC's. Anyone who wants to sponsor
> a feature compiles an RFC on it, and is resposible for keeping track of
> the discussion on it, and occasionally rolling the comments back into a
> new revision of the RFC.
>
> What do you guys think of something like this? We could even mark
> certain RFC's as "Dead for now", or something like, so that we can kill
> threads such as {}, and anyone who doubts the "deadness" of the thread
> can check the status of the RFC before commenting.
>
> One potential risk I see with this approach: Someone sponsors a certain
> RFC, goes through much time and trouble to track and merge discussion,
> only to have it "killed" somewhere down the road by the others. This
> could possibly lead to the kinds of flare-ups that occur from
> time-to-time on php-dev...

Zak wrote:
> That sounds like a very good idea. We spend a good deal of time going
> around.
> The RFC process should have a series of significant benefits:
>
> a.) Less digging through old mail to figure out what was said
>
> b.) The sponsor must be serious
>
> c.) The process of writing an RFC will encourage the sponsor to consider
the
> feature more carefully
>
> d.) The RFCs will provide a form that can easily be archived.
>
> --zak

Zak wrote again:
> Has anyone else had a chance to think about this proposal?
>
> I think that it is a solid idea.
>
> As Joey points out, it might help prevent the pointless go-rounds
> that have been occurring with this discussion *and* would give us a
> clear set of documents to refer to in the future.
>
> --zak






-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]