Re: Overhauling the bugtracker project

Just do whatever you want. --Jani On 08/04/2009 04:43 PM, Brett Bieber wrote:

Hi, Let me begin by saying, the pear2 website is not using pearweb as a starting point. On Tue, Aug 4, 2009 at 6:10 AM, Jani Taskinen<jani@php.net> wrote:

On 08/04/2009 01:50 AM, Brett Bieber wrote:

Hi, I've been looking through the Bugtracker project, examining the feasibility of using it for PEAR2, and it seems like a lot of work would need to be done to use it with a site that does not have roots in phpbugs or pearweb. Currently it is difficult to change how the bugtracker interacts with the site/project/package it's collecting bugs for. If I want to customize how my site functions I have to add in if ($site=='pear2') … at every instance where info about a package is gathered. Currently there are quite a few similar checks for if $site=='php', because a lot of pecl/pear package specifics don't apply to php bugs.

You forgot the main goal totally here which is to get ONE single bugtracker that handless ALL bugs in ALL our sites. The first stage was to come up with some kind of unified code base.

This is interesting. I was under the impression we would be using one codebase. From the GSoC page: "So, this summer the goal is to get the Bugtracker codebase working and likely implemented for the PEAR, PECL and PHP projects." The BUG codebase is one thing. Is the code for the rest of the site NOT intended to be separate?

Within the bug system, there are two main parts that talk to each other. The project site hosting the bugtracker, and the bugs themselves.

Why do they need to "talk" to each other? Define "talk" ?

Here's a few example questions the bugtracker asks the site/project: Is this a valid package? What are the latest releases for this package? Do you want to collect bugs for pseudo packages, like Documentation, Web Site, etc? What do you call your pseudo packages? … <snip> nothing constructive here

So I'm proposing revamping quite a bit of the functions.inc file. Moving everything related to the bugs to a class Bugtracker, and everything related to the site/project as a class that implements interface Bugtracker_Site.

What does this give us over plain functions? Except for another extra file to be included.

Organization. Right now the heart of this bugtracker is a 1500 line file with global functions. Inside this file is a mix of functions related to the site/project and functions related to the bugsdb, as well as html helpers. It is a mess, and assumes each site has a full instance of pearweb or php-bugs-web running. Neither of which I'll be using for pear2. Secondly, this will remove the need for placing if ($site == 'php') … if ($site == 'pear'), or switch ($site) inside each of the functions that retrieve information about the site. <snip> nothing constructive here.

I've started some work on this, and I have a patch that just scratches the surface. But, before I go much further I'd like to know if the leads think this is the correct direction to go. Any feedback would be appreciated as well. Basically I want to know if I can make the modifications I need for using the Bugtracker with PEAR2, or if I should start my own project using the same schema.

No more separate trackers. This thing is supposed to be eventually on one site, on one database.

Then this thing needs some serious work. So, can we agree that this is a good direction to go, given that pear2 will not be using pearweb as a codebase? Would you like some help? Is my help worthy? :-)