- This allow the migration of bugzilla components to a gitlab label.
- Only enable it when you want migrate components. Lots of Xfce does not
have relevant components.

- Not revelant in xfce case

- By using the --resolved switch
- Importing tens of thousands bugs is really slow, I think that's why gnome and fd.o chose to not import resolved bugs.
- However on xfce, it should be doable (only ~15k bugs in total)

Check if the target GitLab project actually has issues enabled, and
enable them before attempting to import if not.

Reported by @ajax.

It's git.fd.o we need to unconditionally allow non-fast-forwards on, not
GitLab ...

Reverts d04d0cb5 ("fdo-import-repo: Allow non-fast-forward pushes").

Apparently sometimes the value is 'author' and sometimes the value is
'creator'. I'm not sure why, but this fixes things on fd.o it seems.

Use a 'sudo' token to act as the author when posting issues, comments,
and attachments.

Don't encode knowledge of GNOME servers into the common script, but only
from the shell.

Signed-off-by: Daniel Stone <daniels@collabora.com>

This removes the unused definition from bztogl.py.

One might not have permission on certain file, or other issue might
happen and it should not fail the process.

The following issue happened import Pitivi:

```
phabricator.APIError: ERR-CONDUIT-CORE: [Access Denied:
Restricted File] (Can View) You do not have permission
to view this object. // thiblahute (Thibault Saunier)
can take this action. The user who uploaded a file can
always view and edit it. Files attached to objects are
visible to users who can view those objects. Thumbnails
are visible only to users who can view the original file.
```

So that we can restart the process where it quitted if an error happend
or the import process was closed

We do not cache Bugzilla users that match the default assignee or the
default QA contact for a component or a product, because the GNOME
Bugzilla instance typically uses fake addresses for those fields. Sadly,
some products over the years decided to use real people as default
assignees and QA contacts, and those people may not have used an email
address that is mapped on any of the GNOME infrastructure services.

This means that as soon as we get a comment from a person who's the
default assignee for a specific bug, we get an empty entry in the users
cache, and it breaks the migration script.

If there is a target milestone given for a bug that is not "---", set the
Gitlab milestone on the migrated issue, creating the Gitlab milestone if
needed. A cache of already existing milestones is fetched up front.

Closes #29

When Yorba moved their application hosting over to GNOME's
infrastructure for Geary, Shotwell, and other projects, the bug
import from their bug tracker produced buzilla bugs containing the
complete bug history in comment 0.

This looks for such import bugs, cleans up the text a bit to to make
it somewhat more readable, and replaces `#1`, `#2`, etc in the text
with `Comment 1`, `Comment 2`, etc so early gitlab issues don't get
spammed with huge numbers of mentions.

If there is a version given for a bug, and it is not "master" or
"unspecified", include a "Version: " line at the bottom of the
description with the version value.

Closes #30

It seems to happen in some rare cases that the bug's creator is not the
first commenter. Handle those cases gracefully.

Closes #25.

Add a phabricator importer

See merge request Incubator/bztogl!28