207514 - Incorporate P4DTI patches into Bugzilla

Status: RESOLVED INVALID

(Bugzilla :: Bugzilla-General, enhancement)

Description

[Gervase Markham [:gerv]]

The Perforce defect tracking interface, P4DTI
(http://www.ravenbrook.com/project/p4dti/), has some patches against Bugzilla to
allow it to work. It would be good, as far as possible, for some of those
patches (or other changes which produced the same function) to become part of
Bugzilla.

I anticipate that those patches which provide hooks, or are otherwise general,
would be most likely to get in. P4DTI-specific UI is probably best added using
template customisation.

Gerv

Comment 1

[Nick Barnes]

Thanks for creating this bug, Gerv.  Here's some more background.

The P4DTI integrates the Perforce software configuration management system
<http://www.perforce.com/> with defect trackers including Bugzilla.  The
integration makes defect tracker records (e.g. Bugzilla bugs) visible inside
Perforce, allowing developers to update bugs from Perforce and also to record
which changes fix (or otherwise affect) which bugs.

This basic functionality does not require any changes to Bugzilla.  However, the
P4DTI also comes with a patch to Bugzilla which presents some Perforce
information in a read-only section of the bug form.  Most usefully, it shows a
table of changes related to the bug, complete with links to a Perforce web
interface for viewing diffs etc.  Here's a screenshot of the form as it appeared
 in Bugzilla 2.12:
<http://www.ravenbrook.com/project/p4dti/master/manual/ug/#section-10.3>.

The P4DTI Bugzilla patch also includes the following other items:

- a "p4dti" parameter (in defparams), defaulting to off, which activates the
P4DTI section on the bug form.

- code to put all the defparams parameters into MySQL, so that the P4DTI can
read them.  This is currently necessary for the emailsuffix parameter (which the
P4DTI uses to establish a correspondence between Perforce users and Bugzilla
users) and may be required for other parameters in future.

- And a small change to Bugzilla 2.14.x to turn off a taint warning.

I'll attach a P4DTI Bugzilla patch to this bug.

The current P4DTI release is 1.5.3
<http://www.ravenbrook.com/project/p4dti/release/1.5.3/>, and supports Bugzilla
2.14.4 and 2.16.1.  I am working on P4DTI version 2.0, and expect to make
release 2.0.0 today, which will support Bugzilla 2.14.5 and 2.16.3.  We aim to
support 2.18 soon after it is released.  We don't support the 2.17.x releases,
as they are "development releases" (although they are generally of higher
quality, and in wider use, than were 2.15, 2.13, or 2.11).

We would obviously like for the whole P4DTI patch to be taken into the Bugzilla
sources.  Failing that, we would settle for some parts of it.

We are also interested in some other changes to Bugzilla which would make
third-party integrations easier, but they undoubtedly belong in other bugs.

Comment 2

[Nick Barnes]

Attachment: P4DTI 1.5.3 patch for Bugzilla 2.16.1

Here's the patch for Bugzilla 2.16.1 from P4DTI release 1.5.3.	This patch also
applies successfully to Bugzilla 2.16.2 and 2.16.3.

Comment 3

[Bradley Baetz (:bbaetz)]

bugform.pl doesnt' exist anymore, so thats one issue :) If you want this as a
patch, you should also patch teh default etmplate, not a custom one

Comment 4

[Nick Barnes]

Yes.  The attached patch is purely for illustration of the P4DTI requirements;
it's absolutely not intended as a candidate patch for inclusion in 2.17.x.

I thought it was inappropriate for a third-party patch to change the default bug
form template, which is why this patch installs a modified copy of it as a
custom template. 

I have had a brief discussion with Gerv about the design possibilities for a
2.18 patch (thanks, Gerv).  The bug_form.pl code will probably move into Bug.pm
as new bug accessor methods.  The template section will probably come out into a
separate file which is PROCESSed into place.  And maybe we can get rid of the
"put the parameters into MySQL" part altogether, by using some HTTP (maybe
related to config.cgi) to allow the P4DTI to obtain the needed parameters.

The questions are, how much of such a patch could be accepted into the Bugzilla
pre-2.18 sources, and how much would have to remain outside as a third-party
patch to be applied by an administrator?  Obviously, I would prefer the answers
to be "all" and "none" respectively.  But what hoops will I have to jump through
to get those answers?

Comment 5

[Gervase Markham [:gerv]]

justdave: ping? Can you make an assessment, and tell Nick how much of his
changes might get into mainline Bugzilla? 

Gerv

Comment 6

[Dave Miller [:justdave]]

Sorry for the slow reply, I'm catching up on about 2 months worth of bugmail...

I don't see any reason we shouldn't put this in if it gets cleaned up for the
current tree layout.

The perforce-related code in the template seems to all be in one spot as far as
I can tell, so it would probably be a worthwhile idea to make the
perforce-section an entirely separate template, and link to it from the bug form
template if the perforce param is on.  The default shipping template can say
something like "you don't have P4DTI installed", and it's an easy matter for the
P4DTI installation to drop in a custom template with their stuff in it.

Likewise, the code needed to generate the template variables for P4DTI could be
in a separate .pm file (distributed with P4DTI rather than Bugzilla) and Bug.pm
can require that .pm file and call into it when the bug.p4dti variable is
referenced from the template.

That way all we actually need in Bugzilla is a dummy template and a param, and
it leaves the important part of the code under P4DTI's control.

Comment 7

[Gervase Markham [:gerv]]

Anyone at Ravenbrook: given what Dave said, are you planning to work on
integrating the P4DTI stuff in that sort of fashion?

Gerv

Comment 8

[Gervase Markham [:gerv]]

Hello again, Ravenbrook people :-) 

We now have a shiny new "Hooks" mechanism to allow you to hook your templates
into Bugzilla without modifying it. So P4DTI should now be basically
distributable as a Bugzilla extension, without patching. 

We'd love to see you try this out and see if it works in practice.

Gerv

Comment 9

[Nick Barnes]

Thanks you guys; trying out the hooks mechanism now and (after a few teething
problems) it works fine.

Comment 10

[Gervase Markham [:gerv]]

Nick: two questions:

- Are your "teething problems" caused by unclear docs? If so, please file bugs.

- Will it be possible for P4DTI for Bugzilla 2.18 to be distributed as a
Bugzilla add-on (i.e. using just hooks and the other customisation mechanisms
we've added)? Dave is working on an extensible mechanism for adding admin
parameters, although I don't know if it's due for 2.18.

If these changes aren't enough, could you summarise (perhaps on the developers
list) what other technical problems there are to solve?

Lastly, as soon as you know where you want them, please file a bug or bugs
(probably one to start with; we can split off any contentious requests) to add
the necessary hooks to the standard Bugzilla templates.

Thanks :-)

Gerv

Comment 11

[Nick Barnes]

The main teething problem was bug 239112 and the TT version.  Shall I file a bug
against cust-hooks.html?
Other than that it was me trying to grok TT.

I have made bug 239346 for the hook which we need.  I note that editparams.cgi
is table-driven from defparams.pl rather than being a template, so our change
here will remain as a patch to defparams.pl (until there's code for custom admin
parameters; is there a bug number for that?).

The other thing we would like to see in Bugzilla itself is a replacement for
processmail (bug 239343).  Then there's some code to read the P4DTI tables and
stuff them into hashes and arrays for our hook to display, but I expect that
will remain as a separate patch that comes with P4DTI.

I have also been considering a change to Bugzilla to mark bugs as "changed".  At
the moment we have to do some rather ugly digging around to spot which bugs have
changed since the last time we looked (including catching fencepost problems
when lots of things change in one second).  Such a thing would be useful for
anyone replicating data out of Bugzilla.  But it's much more speculative.

Comment 12

[Myk Melez [:myk] [@mykmelez]]

>I note that editparams.cgi
>is table-driven from defparams.pl rather than being a template, so our change
>here will remain as a patch to defparams.pl (until there's code for custom
>admin parameters; is there a bug number for that?).
...
>Then there's some code to read the P4DTI tables and
>stuff them into hashes and arrays for our hook to display, but I expect
>that will remain as a separate patch that comes with P4DTI.

We need a hooks mechanism for the Perl code in Bugzilla just like the one we now
have for Template code.  That should obviate the need to patch defparams.pl and
show_bug.cgi, even without custom admin parameters.  It should be simple to
code, and it would be great to get it into 2.18, but I'm not sure anyone has the
time to work on it.

Comment 13

[Gervase Markham [:gerv]]

> (until there's code for custom admin parameters; is there a bug number for 
> that?)

Bug 46296.

> The other thing we would like to see in Bugzilla itself is a replacement for
> processmail (bug 239343).

Sure; but you can ship that yourself if necessary without touching Bugzilla
code, right? So it's less important than the stuff which requires you to patch
Bugzilla files.

Gerv

Comment 14

[Dave Miller [:justdave]]

Reassigning bugs that I'm not actively working on to the default component owner
in order to try to make some sanity out of my personal buglist.  This doesn't
mean the bug isn't being dealt with, just that I'm not the one doing it.  If you
are dealing with this bug, please assign it to yourself.

Comment 15

[Wayne Mery (:wsmwk)]

Is Ravenbrook/Nick gone?

Comment 16

[Nick Barnes]

Not gone, just really, really busy.

Comment 17

[Max Kanat-Alexander]

Nowadays I'm not sure if anything in this bug makes sense to integrate anymore.

If it does, I'd really like specific patches, and you can add [p4dti] to the whiteboard on those specific bugs.

Nowadays we have hooks for templates and code, extendable admin parameters, and custom fields. I don't think anything else is needed.