[GNC-dev] Bugzilla Keywords -- keep or drop (and which ones)?

[Frank H. Ellenberger]

Am 14.05.2018 um 18:10 schrieb Derek Atkins:
> Hi,
> 
> On Mon, May 14, 2018 11:41 am, John Ralls wrote:
>>
>>
>> The existing keywords don’t seem terribly useful to me and they’re in any
>> case not used consistently enough: only 364 out of 8590 GnuCash bugs have
>> a keyword on them. I don’t think that there’s any need to import them
>> unless BZ requires it.

Some are only useful, for a QA with a team like that of gnome. Others
were much more useful, if we would apply them more consistently.
Example: "Documentation" should be set already, if something has to be
fixed in engine first, but also needs documentation. Then after engine
is fixed, it should not be closed as fixed. Instead it should be
reassigned to documentation.

So which we should drop, we should decide in a later step.

>> If you do have to create them, do so and then back up the keyworddefs
>> table using MySQL; you can then easily restore the table when you recreate
>> the db.
> 
> It was easy enough to extract the fieds from gnome-bz into json, so I have
> the list of defined keywords.  And it was easy enough to write some code
> to add them to the database programatically during the migration before I
> insert any data.  So that's what I did.
> 
> So for now I am going to duplicate all the gnome keywords and allow the
> bugs to retain them.  Then we can go through and remove any that are
> superfluous.
> 
> I'm going to run the next try import and see how it behaves.  I have (for
> now) removed the dup_id fields from the import data, which I think means
> we wont properly get duplicates marked in the database.  We'll see how
> this goes and how it all looks.  The problem I'm seeing when I leave the
> dup_iud field is that I get an error from the migration script:
> 
> Starting to create Bug 84690
> Can't use string ("Bugzilla::Bug") as a HASH ref while "strict refs" in
> use at Bugzilla/Bug.pm line 3322.
> 
> I will continue to explore this issue.

The default policy was: close the younger report, but there are
exceptions i.e. the younger report had much more useful information, in
particular attachments.

To reduce conflicts process the bug list sorted by id;
ProcessBug (ID):
  If  the bug is not already imported {
    if it is duplicate ProcessBug (duplicate_of);
    continue
    }

>> Regards,
>> John Ralls
> 
> -derek
> 

~Frank