[p4] P4DTI modifications to support BZ flags (was -- RE: p4DTI in Perl ?)
Nick Barnes
Nick.Barnes at pobox.com
Sun Jun 25 01:37:52 PDT 2006
At 2006-06-24 13:22:58+0000, "Jay Glanville" writes:
> Richard, so you've made changes to the P4DTI to support Bugzilla flags?
> Interesting!
>
> Is it possible to share the modifications you've made? I'd be
> interested in such functionality. Nick, would Ravenbrook be interested
> in incorporating such functionality into it's next release of P4DTI?
Yes.
The main reason the P4DTI doesn't currently replicate flags is that
they would require quite a complex representation on the Perforce
side, which can't be enforced by the jobs system and so I suspect it
would lead to a much higher failure rate when replicating malformed
flags back to Bugzilla.
For instance a request for user "fred" to apply flag "blocking-2.22"
would have to look something like this:
blocking-2.22? (fred)
If Fred confirmed the flag, it would look like this:
blocking-2.22+
If he declined it, it would look like this:
blocking-2.22-
A typical Bugzilla bug has a number of flags set, so several such
strings would have to be combined into a single 'flags' field in the
job, like this:
blocking-2.22? (fred), blocking-2.23.1? (fred), approved-2.20+, security? (alex)
And in the Perforce job the only type-checking provided would be that
this is a field of type "line".
The code to replicate a field like this from a bug's flags is really
quite simple. But I hate to think what will happen to a field like
this under the tender mercies of a thousand developers, and the P4DTI
will have to cope with the results, and try to replicate them back to
Bugzilla.
Richard, can you go into some more detail on how you cope with this
problem?
Nick B
More information about the perforce-user
mailing list