Moving bugs to Phabricator
Daniel Stone
daniel at fooishbar.org
Tue Feb 2 15:43:21 UTC 2016
Hi,
As previously discussed with a few people (when it was much more in
its infancy than now), I'd like to move our bug tracking from Bugzilla
to Phabricator.
There's a few reasons behind this. Phabricator is actually a pretty
decent suite of utilities, including repository browsing and code
review (Gerrit-style, including iterative revisions of patches,
line-by-line comments, etc), and having our bugs in that would allow
us better integration between the two. For instance, putting
'Maniphest Tasks: T1234' in a commit message when uploading a diff
automatically links the commit and the bug, and similarly it also gets
closed when pushing commits.
We can push this out further as well, including automatically
triggering CI from commits sent for review. I actually had this
working last year (running distcheck for every commit), but am in the
middle of rejigging my setup for a few things and haven't yet fixed
that to happen again yet.
Personally, just the improved UI (BZ is a nightmare) is enough for me,
but in terms of what we can do with it in future, I think it's got a
much better model than Bugzilla. The data store in Phabricator is very
important to their upstream, and is sensible and extensible. Whilst
We've had an instance at fd.o for a while, which has been used to
varying degrees by projects such as PiTiVi, GStreamer, et al. Also, we
use it internally for everything at Collabora, so the tree we maintain
for use there also gets pushed to fd.o.
In terms of what this would mean mechanically, we already have a
fairly mature suite of scripts which have been used to do imports for
quite a few projects. Using this would mirror all the Bugzilla bugs to
Phabricator, add a link from the existing Bugzilla bugs to their
replacements on Phabricator, and then redirect all new bug-filers to
Phabricator. The import process also creates accounts for everyone, so
once they'd recovered their passwords, so no data will be lost. It
also ports attachments over.
Beyond that, we can start using code review for it as and when people
feel comfortable, particularly using git-phab, which submits patchsets
to Phabricator for review. I'm probably most excited about getting
review on there, though also fairly cautious; while Bugzilla is just
trading one antiquated web tool which no-one uses for a nice modern
one which equally few people will probably look at, review is a bigger
part. Nonetheless, having things like concrete review approval status,
line-by-line review separated from wider/conceptual review,
at-a-glance review status, etc, I think is valuable enough that I
think it's worth shifting things over at some point.
Anyone have any thoughts/opinions/fears/encouragement?
Cheers,
Daniel
More information about the wayland-devel
mailing list