I think it would be great to have something like a wiki for proposals
and requests for a start.
However, the discussion on these topics shouldn't be moved to the wiki
(-> quite annoying); maybe a forum would be adequate.
Problematic: the wiki has to be kept up-to-date with the discussion in
the forum on a specific topic.
Bug-/Feature-tracking systems are also a very nice idea, but they're
often oversized and not very intuitive to use, especially for newbies
and those who just want to contribute a patch (depends on the system, of
course).
Maurice.
Is there a PHP/Zend bug-tracking system that can be used to record and
moderate these requests (like a Bugzilla server somewhere)? Or is there a
wiki or forum that that can be devoted to the change-process?
(Sorry for these n00b questions - I'm a long time PHP hacker - but
I've only
recently became interested in PHP/Zend development).
-- Jim
On 2/9/07, LAUPRETRE François (P) <[EMAIL PROTECTED]> wrote:
I proposed several times to make the process more formal, with a real
RFC
process. It does not
have to be more complex than what the Zend Framework uses. I never
had any
reply...
As time passes, I also start to be fed up with these feature removals. I
also start suspecting
some people to have an interest in the current lack of transparency
concerning the decision
process in general.
IMO, the mailing list is not the best tool for RFCs, and we all know
that
a number of
interesting proposals were ignored because :
- either there was another discussion/flamewar going on at the
same time, and it was lost
in the flow.
- or the proposal did not come from a group of ~10/15 core
people.
I am pretty sure that
most of these people only read messages coming from their peers. It
is OK
because they
certainly cannot read everything, but it illustrates the need for
another
space for RFCs.
The other reason why I want a dedicated RFC space is history. Every day,
you see messages
saying 'I don't remember...', 'what did we decide... ?'. There is no
place
with decision
history. So, the same subject is regularly discussed again and again.
I am sure you will appreciate that the only document we have to justify
removing ereg from the
core distribution is in http://www.php.net/~derick. Sorry to say that,
Derick, but please admit
that this kind of information should go to a more 'official' place.
Regards
Francois
> -----Original Message-----
> From: Jim Wilson [mailto:[EMAIL PROTECTED]
> Sent: Friday, February 09, 2007 6:52 PM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] RE : [PHP-DEV] Re: [PHP-CVS] cvs:
> php-src(PHP_5_2) / run-tests.php
>
>
> On that note - is there a formal process in place for
> deciding what gets moved from PCEL to 'Optional Extension'
> and vice-versa? Who has final say in the matter?
>
> -- Jim
>
> On 2/9/07, LAUPRETRE François (P) <[EMAIL PROTECTED]> wrote:
> >
> > > From: Derick Rethans [mailto:[EMAIL PROTECTED]
> > >
> > > On Thu, 8 Feb 2007, Adam Maccabee Trachtenberg wrote:
> > >
> > > > I read this as saying we're removing the entire ereg extension
> > > > from PHP 6. If that's not true, then never mind.
> > >
> > > http://www.php.net/~derick/meeting-notes.html#move-ereg-to-pecl
> >
> > From what I read there, it was decided to unbudle the regex library
> > and to make ereg an extension, not to move this new ereg
> extension to
> > PECL. There is a big difference
> > between making ereg an optional feature and moving it to PECL !
> >
> > So, as I am tired to see features I use every day planned
> for removal
> > from the core, I'd like to see another justification. IMHO,
> the ereg
> > extension should be changed
> > to an optional extension, but bundled with the PHP distribution.
> >
> > François
> >
> >
> >
> > --
> > 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
