Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » bug tracker merging »

bug tracker merging

php.internals

Greg Beaver

19 years ago
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 1) patch tracker complete with versioned patches 2) roadmap support with auto-generation of package.xml based on closed bugs/features 3) 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

Steph

19 years ago
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

Greg Beaver

19 years ago
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

Jani Taskinen

19 years ago
I read this email *AFTER* discussing with Gregory in IRC about current situation of having 3 separate bug trackers in *.php.net. So now I'm hijacking this coincidentally related thread for informing what happened during/after the discussion. :D Gregory Beaver kirjoitti:
> 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
I agreed with Gregory that the PEAR version of the original PHP bug tracker code is the best starting point for unified codebase. So now there is pear/Bugtracker in CVS which Gregory created from the current PEAR bug tracker code. This will be the base for the übertracker.
> 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
I'm dividing the task in hand first into 2 phases required to kickstart this: Phase I (one): - Unified codebase that works for PEAR/PECL/PHP bug trackers using their own databases. (*) * Basically all changes/additions are needed only for current PHP bug db, PEAR/PECL both share the "package/type" concept already. This is my first TODO. Phase II (two): - Add "project" concept into the tracker and merge each database into one, http://bugs.php.net/ will be the only bugtracker for *.php.net, [pear|pecl].php.net/bugs/ can just be redirected there..not to forget php-gtk, etc. When projects are in DB, adding one more will not be hard. :) ..more phases will propably come up later, these 2 are the main targets now.
> 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 ;)
I will ignore any unit tests for now. :) --Jani p.s. Any volunteers: You're not needed right now..and most likely not later either. (this is friendly hint to everyone: keep your hands off! :) p.p.s I refuse to discuss things like coding style, using pear/not using pear stuff..etc. Focus!

Jacques Marneweck

19 years ago
Are you using PHPUnit for the unit tests? Also there was some alert stuff that Jim Winstead if I remember correctly was wanting to hook into the mix (it's all commented out from my last look at the bugsweb code), which would be great to allow devs to subscribe to bugs (package / project / etc.) that interests them. Regards --jm On 30 May 2007, at 11:41 PM, Jani Taskinen wrote:

Greg Beaver

19 years ago
Jacques Marneweck wrote:
> Are you using PHPUnit for the unit tests? > > Also there was some alert stuff that Jim Winstead if I remember correctly > was wanting to hook into the mix (it's all commented out from my last > look at > the bugsweb code), which would be great to allow devs to subscribe to bugs > (package / project / etc.) that interests them.
Hello Jacques, As you can see for example in http://pear.php.net/bugs/bug.php?id=11195 subscription to bugs is already supported in the PEAR bug tracker, and so will be supported in the combined tracker. In answer to your second question:
> On 30 May 2007, at 11:41 PM, Jani Taskinen wrote:
[snip]