Hi all,
I'm a bit concerned by the headlong rush to refactor phpbugsweb to
include PEAR and PECL bugs. The concept is fine by me, but starting
with phpbugsweb as the starting point is a big mistake if you plan to
include PEAR bugs. The PEAR bug tracker has several killer features
that you will have to pry from my cold dead fingers before I would
accept a merge with the phpbugsweb
- patch tracker complete with versioned patches
- roadmap support with auto-generation of package.xml based on closed
bugs/features - limited-privilege accounts eliminate the need for CAPTCHA altogether
(all you need is the ability to check email and fill in a form with name
and password after the fact). We haven't had any spam bugs since
implementation and it is more handicapper-accessible.
http://pear.php.net/bugs/report.php?package=PEAR_ErrorStack to see an
example, all that is required is a valid email address and the ability
to add or subtract numbers between 1 and 100
The main problem with the codebase of pearweb/bugs is that it depends on
the core of pearweb (bad) and so needs to be independentized, but we are
doing this ASAP. roadmap for the website is at
http://pear.php.net/bugs/roadmap.php?package=pearweb
Of course, it's also in the process of being refactored along with the
rest of pearweb (unit tests gasp) so please don't discount a look at
this codebase, no matter how bigoted against PEAR you might be ;)
Greg
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.
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?
- Steph
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