Hi,
I can offer to do the initial patch of Bugzilla.pm for 3.0, including all
the discussions/patches I've had with Kristis in the past, excluding those
two methods:
integration_get_vdd
integration_get_bugs
We could share work...
Dmitri could you then get those two methods running with 3.0?
To do so, I would check out lastest code from CVS.
@Kristis: Do we need to freeze this code until we have a running patch for
Bugzilla.pm?
It's just a suggestion, if you want to make it on you own Dmitri, no prob.
Let me know soon, as I have resources tomorrow to do this.
Kind regards,
Oliver
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dmitri Colebatch
Sent: Monday, June 04, 2007 2:36 PM
To: Kristis Makris
Cc: [email protected]
Subject: Re: [scmbug-users] Bugzilla 3.0
Hi Kristis,
Thanks for the response, one comment inline:
On 6/4/07, Kristis Makris <[EMAIL PROTECTED]> wrote:
> 2 - Why create a Bugzilla3.pm ? It's not necessary. I would claim
> breaking it up will cause things missing in Bugzilla3.pm when new
> integration_* functions are added (e.g. as they have been added right
> now in a patch I've been working on for autolinkification) -- why
> maintain essentially an extra backend, and duplicate code ? It's not
> "messy code". It a concise design.
>
> I'd rather you integrated the 3.0 work in the existing Bugzilla.pm. A
> Bugzilla3.pm would be workable, but I feel it would cause more
> problems than the ones it attempts to solve.
Firstly, I don't mean to sound like I'm picking on your code, happy to be
wrong, just looking for the cleanest solution.
The reason I was thinking that a separate class might be cleaner is the
integration_get_product_name method - using the code attached to the bug
this doesn't require database access, so that method would become something
like (from memory):
sub integration_get_product_name {
my $self = shift;
my $bugid = shift;
my $bug_product_name;
if ($self->isBugzilla3()) {
my $bug = new Bugzilla::Bug($bugid));
$bug_product_name = $bug->product->id;
} else {
.... existing code
}
return $bug_product_name;
}
Two things about the above:
1. Should we rename is_version_latest latest to is_version_2_22 and add a
is_version_3_0?
2. The above is going to get more and more complicated as more of these
variations are added. As a java developer, I'd have something
like:
interface BugTrackingInterface { ... }
abstract class AbstractSQLSupport { ... } class Bugzilla18 extends
AbstractSQLSupport implements BugTrackingInterface { ... } class Bugzilla20
extends AbstractSQLSupport implements BugTrackingInterface { ... } class
Bugzilla22 extends AbstractSQLSupport implements BugTrackingInterface { ...
} class Bugzilla30 implements BugTrackingInterface { ... }
and then have the appropriate instance chosen. Unfortunately my perl is not
strong enough to know how to model the above in perl but the point I'm
trying to get across is having a separate implementation for each version
(with re-use where appropriate).
I'm just about done for today but will take a look at this tomorrow morning.
I'll try to take a look at this tomorrow and hope to have something
substantial to show for it pending other interruptions.
cheers,
dim
_______________________________________________
scmbug-users mailing list
[email protected]
http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
_______________________________________________
scmbug-users mailing list
[email protected]
http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
