Re: Bugs mailing list

Chuck Hagenbuch wrote: > Quoting Greg Beaver <greg@chiaraquartet.net>: > >> Yup - this would be stellar. I'll tell you what - I'll make it really >> easy to install and distribute whatever is written by making Pyrus >> frickin awesome, and will provide moral support for any such attempt to >> write a php-based trac > > Do we really have to encourage people to reinvent the wheel instead of > improving and working with existing PHP projects (setting aside the "it > should be PHP" argument for now) that already exist, that already use > some PEAR libs, that use most PEAR-style conventions? The same sentiment > showed up on the Zend Framework lists when they first started using trac > (which worked much better than their current java-based tools, at > least). Not invented here, to the utmost. Hi Chuck, I realize I was subtle, but if you read carefully what I wrote, I actually said I won't be involved in writing a single line of code for the project, just writing an installer that will make it easy to install :). If Travis wants to do something interesting, I don't see a reason to discourage it, this being open source. That's what I meant by "moral support." I am incidentally well aware of Horde's bugtracker - we looked at a gazillion bug tracker options before deciding to stick with the current codebase for PEAR's bug tracker, simply because, as Josh said, migrating would be a royal PITA for a full-time engineer, and we're all less-than-part-time hackers. As for the "it should be PHP" argument, all I was saying is that *.php.net runs PHP software as a basic principle, and this is not something that I or any of us PEARites control. I happen to like features of Trac, but as Josh said and I alluded to, writing a script for svn.pear.php.net to parse comments for bug numbers and providing a way to link to the bugtracker is trivial, and most certainly will be implemented. The same task for cvs.php.net is extremely arduous since the script would need to ignore every non-PEAR repository commit, and would require direct access to the delicate CVSROOT, something that I have done once, and hope to God I never need to do again. The stress of maybe screwing it up with no way of being sure it would work until it did nearly killed me :). Greg