[GNC-dev] BZ: Currently Ignored Fields

[John Ralls]

> On May 21, 2018, at 1:12 PM, Derek Atkins <derek at ihtfp.com> wrote:
> 
> Hi,
> 
> I've been working with John today iterating over the BZ Migration.
> 
> At this point I think we've got the Status, Resolution, and Work Flow
> worked out.  I've removed field values that do not apply to us, and I've
> added the Gnome field values that we actually use.
> 
> I think what's left, at this point, is dealing with some additional data
> that I currently toss out during the migration/import.   At least one of
> these is a Gnome-BZ extension, but we should decide what, if anything, we
> want to do about these:
> 
> Products:
>  I set the "version" to "3.0" -- I'm not sure exactly what that means or
> what effect that has.
> 
> Product Components:
>  I'm deleting the sort_key and flag_types fields I downloaded from GnomeBZ
> 
> In Bugs I'm deleting:
>  cf_gnome_version
>  cf_gnome_target
>  is_open
>  flags
> 
> In Bug Comments I'm deleting:
>  attachment_id
>  count
>  author (not sure the difference between this and the creator/"who")
>  time (not sure the difference between this and bug_when/creation_time)
> 
> In Bug History:
>  I'm not sure if "groups" == "bug_group"
>  Because the two cf_gnome_* fields don't exist, I have to change those
>     in bug history.
>  attachments.gnome_attachment_status does not exist, so I have to change
>     that, too, in the history.
> 
> In Bug Attachments, I'm deleting:
>  attacher
>  flags
>  summary
>  last_change_time
>  size
> 
> I suspect there is a lot of data hidden in the various "flags" elements
> that I'm just deleting during the import.  I know for sure that the
> gnome_attachment_status data is not getting imported, but I don't know
> where it can be found exactly.  There are 507 bugs that use this field.
> 
> I also don't know if I'm properly handling comments on attachments.  C.f.
> Bug #630652 for an example.
> 
> -derek
> 
> PS: These field names are a combination of JSON fields obtained from the
> JSON API, and the Perl/DB fields.

Searching bugzilla.gnome.org turns up exactly one bug [1] with a flag set and it's not one of ours. I don't think we need to worry about there being any data hidden in any of the flags fields.

I found this for gnome_attachment_status: https://git.gnome.org/browse/bugzilla-gnome-org-customizations/log/?qt=grep&q=gnomeattachmentstatus are at least some of the relevant customizations Gnome made to Bugzilla 4.4. While it's a nice feature I'd rather that we don't customize BZ's code if we can avoid it, and I'd actually prefer that we push anyone making a non-trivial patch to doing it as a Github PR instead, so maybe not really worth too much effort. We have well over 900 bugs with patches against them, but only 39 *open* ones. Only about half have status other than "none" so we clearly haven't been to assiduous in marking the status anyway.

In Bugs, groups is the user groups (e.g. GnuCash Developers) who can view the bug. Exactly one [2] was limited and it appears to have not imported. I've unprotected it in bz.gnome.

In Comments, "author" and "time" are redundant to "creator" and "creation_time" respectively for backward (*from* 4.4) compatibility. Count seems to regenerate itself. Unlike for bugs you're not keeping attachment numbers so you're right to remove them from comments.

In Attachements, attacher is redundant to creator and summary to description. Without gnome_attachment_status the last_change_time is probably not that important and it can anyway be retrieved from history, and size is probably computed anyway. 

Looks like we're close and can start thinking about configuring BZ unless you want to do something with gnome_attachment_status.

Regards,
John Ralls


[1] https://bugzilla.gnome.org/show_bug.cgi?id=626399
[2] https://bugzilla.gnome.org/show_bug.cgi?id=619984