Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:29963
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain chiaraquartet.net from 66.79.163.178 cause and error)
Message-ID: <465DC5D8.3060309@chiaraquartet.net>
Date: Wed, 30 May 2007 13:43:36 -0500
User-Agent: Thunderbird 1.5.0.10 (X11/20070306)
MIME-Version: 1.0
To: Steph Fox <steph@zend.com>
CC: internals Mailing List <internals@lists.php.net>
References: <465DA8F9.2020001@chiaraquartet.net> <035d01c7a2e9$6a99ea20$39dc2f52@foxbox>
In-Reply-To: <035d01c7a2e9$6a99ea20$39dc2f52@foxbox>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] bug tracker merging
From: greg@chiaraquartet.net (Gregory Beaver)

Steph Fox wrote:
> Hey Greg,
>
>> I'm a bit concerned by the headlong rush to refactor phpbugsweb to
>> include PEAR and PECL bugs.
>
> DON'T PANIC!  There's not really a headlong rush to combine them all,
> it's just Marcus brainstorming and me agreeing for the sake of the
> PECL devs (especially but not only those with core extensions.) I
> don't think you'll find any consensus to add PEAR bugs into the mix,
> not least because there's no confusion there.
:)

I'm 100% in favor of moving pecl bugs off of pb12 and combining with
bugs.php.net.  This is long overdue.

> The only reason I'm opining at all is that I've been going through CVS
> commits with a fine-toothed comb for the Zend weeklies for the last
> three years and some. I can tell you exactly who does or doesn't
> observe the existing conventions; who develops in HEAD and who
> develops in 5_2, who merges and who doesn't; who remembers to add
> MFB/MFH, and who remembers to add any info other than MFB/MFH to the
> merge comment. The core devs generally respect reference numbers far
> more than they do descriptive text, and the vast majority of commits
> are 'quickies' like test script additions/changes, ws/cs or one-line
> improvements rather than bug fixes or major changes in the core API.
>
> There's a lot of unspoken resistance to PHP 6 when it comes to MFB
> because the _internal_ code (not the userland code) can be very
> different there, so merging even a simple one-liner isn't always a
> straightforward process. Who knows how many 'spur-of-the-moment' fixes
> for 5_2 are abandoned because the author doesn't have time to evaluate
> their impact on HEAD? 
This is also a tricky one.  It's true that even my uber-simple
__HALT_COMPILER(); patch required some unintuitive changes to completely
different code areas in order to make it work, and it took a long time
of valgrinding and gdbing to figure this out.

Greg