Re: bug tracker merging

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