[OpenStack-Infra] A proposal to use phabricator for issue tracking

Monty Taylor mordred at inaugust.com
Fri Apr 3 15:00:34 UTC 2015


As a follow up to my previous email about thinking about ceasing to use
storyboard, I have done some work towards investigating using phabricator.

phabricator came out of Facebook, but has been spun out completely and
is now managed as an Open Source project. There is a company that has
formed around it doing support and hosted installs ... so it has a
vibrant and active developer community working on it.

In our broader infra ecosystem, we do lots of things with the Wikimedia
Foundation. They are close collaborators on Jenkins Job Builder, and are
also zuul users. They have recently migrated their bug tracking to
phabricator ... so one could imagine that our collaboration could
continue nicely.

There are several phabricator features we are not interested in - such
as code review. Luckily it is easy to turn them off.

The phabricator model is not exactly what we want, but there are some
nice things about it. It doesn't fully encompass things our
project-group/project/branch hierarchy as it relates to things. However,
it does allow for an issue to have multiple other issues it's blocked
on, as well as multiple issues it blocks. And an issue can be associated
with more than one "project"

A "project" is actually more like an arbitrary tag. That's bad in that
it's not a structured concept. It's good in that it's flexible. A
"project also carries with it an kanban-like workboard, that allows for
different priority setting on a per-project basis.

In any case - it's hard to think about those things without something to
look at, so I set up a phabricator instance and did a data
transformation of the current (ish) storyboard database:

http://15.126.194.141/

If you have ever logged in to storyboard, you have a login here with a
password of "password". As you might imagine, I do not consider the data
in this instance precious - I may or may not blow it away and reload it
from newer database dumps or from improved data migration scripts at any
time.

You may want to note the workboard concept:

The issue:

http://15.126.194.141/T2298

Is in both the openstack-infra/system-config and the openstack-ci
projects. Each of those have a workboard:

http://15.126.194.141/tag/openstack-infra_system-config/
http://15.126.194.141/tag/openstack-ci/

T2298 is in the backlog for openstack-infra/system-config but listed in
priority efforts for openstack-ci.

Also, you can see that T2298 has a "pholio mock" -
http://15.126.194.141/M1 - which is an image with design conversation
associated with it.

The code to deploy this as well as do the data transformation can be
found here:

https://github.com/emonty/puppet-phabricator

It's not perfect - but I figured that a conversation can't really be had
without something to point at.



More information about the OpenStack-Infra mailing list