<div dir="ltr">This proposal is all well and good, however (no offense intended) Monty's got a history of putting out neat proposals and leaving "someone else" to support it. Without identifying a dedicated person/resource that will maintain phabricator, any discussion is moot.<div dir="ltr"><div><br></div><div><div>Michael</div></div></div><br><div class="gmail_quote">On Fri, Apr 3, 2015 at 8:16 AM Thierry Carrez <<a href="mailto:thierry@openstack.org" target="_blank">thierry@openstack.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Monty Taylor wrote:<br>
> As a follow up to my previous email about thinking about ceasing to use<br>
> storyboard, I have done some work towards investigating using phabricator.<br>
> [...]<br>
<br>
For the record, I'll repost some of the analysis I did for mordred on this.<br>
<br>
<br>
Main blocker: Ability to track tasks across projects/branches<br>
------------------------------<u></u><u></u>------------------------------<u></u><u></u>-<br>
<br>
One of the main features we need from a task tracker in OpenStack is the<br>
ability to track the completion of tasks across projects and branches.<br>
That affects vulnerability management, bug backports, and generally<br>
cross-project work. The fact that Launchpad has a limitation there (on<br>
the number of tasks it supports before timeouting) is issue #2 with LP.<br>
The problem is stated once, then a number of tasks affecting different<br>
groups are created, and the issue is closed when the last task is completed.<br>
<br>
In Maniphest as it stands, that would translate into one of those:<br>
<br>
1- Create a single task that affects multiple "projects"<br>
2- Create a main task and multiple subtasks, one for each "project"<br>
<br>
The main issue with (1) is that you can't track partial completion (i.e.<br>
which groups have completed their task and which haven't), which is the<br>
main goal of using a common task tracker.<br>
<br>
The main issue with (2) is that it's difficult to see what groups are<br>
affected from the "main" task (since it only lists task names), and the<br>
main task is not autoclosed when the last subtask is closed (requiring<br>
manual intervention).<br>
<br>
In both cases, the UI allows multiple "projects" to apply to a given<br>
task, which is great for tagging, but not so great when you want to<br>
track tasks per affected repository and branches. Finally, there is no<br>
concept of branches -- we would have to create one project for every<br>
repo/branch combinations.<br>
<br>
Finally, "projects" have no relationship between them. So even if you<br>
associated a task to project "openstack/nova--master" you would have to<br>
also manually associate it to project "nova" (as in openstack/nova +<br>
openstack/python-novaclient) so that Nova team members could also find<br>
it there. There is basically no projectgroup concept, which is issue #3<br>
we have with Launchpad.<br>
<br>
In summary, I think Phabricator's "projects" concept is a (really) neat<br>
*tagging* system, with associated dashboard and all. It's just not meant<br>
to cover multiple "projects" in the OpenStack sense. Our projects have a<br>
few properties which make them difficult to emulate with Phabricator's<br>
"projects": there should be only one per task, they have an affected<br>
branch (master, juno...), and they are grouped into higher-level<br>
structures that can be searched and browsed as well.<br>
<br>
Phabricator seems to be sized for single separate projects, and it's<br>
"project" concept is just a way to organize work within that single<br>
project. It is pretty obvious when you see what happens if you click one<br>
of their "projects": you end up in a dashboard with one item per bug.<br>
Imagine clicking openstack/nova and landing on a dashboard with<br>
thousands of bugs: it's just not meant to be used for that. It is<br>
excellent for tracking a subset of tasks and organizing them, but not as<br>
a higher-level structure.<br>
<br>
So in order to make it work, we'd need a whole new concept added, let's<br>
call it "repository". Each repository may have multiple branches<br>
associated with it. When you create a task, you select a repository and<br>
a branch (and only one). That field is clearly shown in the task name<br>
(no need to drill down to the subtask to find which repo/branch is<br>
actually affected by the task). Clicking on that will bring you to a<br>
list of bugs affecting that repository. Repositories can be grouped<br>
arbitrarily into repogroups which let you search and navigate issues in<br>
a set of repositories, rather than force everyone to rebuild queries to<br>
find, say, "all infra issues".<br>
<br>
Then we could encode a rule so that when the last subtask of a repo-less<br>
task is closed, the parent task is auto-closed. Then that /could/ all<br>
work for task coordination for OpenStack, although it would be slightly<br>
less convenient than Launchpad or StoryBoard (which do not require you<br>
to drill down to update subtasks, and keep the discussion in one single<br>
place).<br>
<br>
<br>
Could do a lot better: CLI/API<br>
------------------------------<br>
<br>
One of the main pain points with Launchpad is its partial API.<br>
Phabricator comes with the "arc" tool, but it is designed to drive the<br>
DVCS git-like featureset. There is no CLI for Maniphest, only a shortcut<br>
to make raw Conduit (API) calls. The Conduit API itself looks<br>
mostly undocumented and (2) "making Conduit more robust isn't currently<br>
a major project priority because there isn't much demand for it outside<br>
of internal scripts".<br>
<br>
We rely on a lot of scripting to interface with Launchpad, which is why<br>
a complete and clean API was such a significant part in StoryBoard<br>
design. It looks like the Maniphest story on APIs is actually worse than<br>
Launchpad.<br>
<br>
<br>
Could do better: Tracking feature development<br>
------------------------------<u></u><u></u>---------------<br>
<br>
A feature is a complex task for which you want specific rules to apply<br>
(like tasks may only affect master branch). It's good to visually<br>
separate them too, so that feature-frozen period clearly excludes them.<br>
Communicating the % of feature completion is also valuable information.<br>
Being able to order subtasks is a nice add too.<br>
<br>
Maniphest has no concept of task types, although it could be emulated<br>
with a "project" (we'd tag all features with a "feature" project), or we<br>
could use a custom field for that. It doesn't have a concept of feature<br>
completion status either. Ideally that would be derived from the number<br>
of completed subtasks, or set by the user on the top task. The absence<br>
of a story (or task group) might bite us here (since in Maniphest<br>
everything is a task, and completion only makes sense on a task group).<br>
Also you can't order subtasks in Maniphest at all.<br>
<br>
Not sure how to solve this one, and improvements around feature tracking<br>
are the #1 reason for StoryBoard to exist. But one could argue that it<br>
won't be worse than using Launchpad anyway.<br>
<br>
<br>
Could do better: ACLs for Vulnerability management<br>
------------------------------<u></u><u></u>--------------------<br>
<br>
Vulnerability management is about the ability to file a report that is<br>
originally only seen by its reporter and a specific team. Then we<br>
gradually add people to the ACL as we pull them in to help with<br>
resolution, up to the point where the bug is open.<br>
<br>
While Maniphest has task ACL support, it is pretty crude. There seem to<br>
be no way to encourage people to file security reports privately (they<br>
have to find out and make use of the "Visible To" and "Editable By"<br>
dropboxes by themselves). Then there is no way short of defining a<br>
"Custom policy" for a user to say ("me and the VMT"). Then there is no<br>
way (short of expanding the custom policy) for the VMT to add<br>
individuals to the ACL.<br>
<br>
For this one to work, we'd need a way to encourage people to file<br>
vulnerabilities the right way (some sort of task creation template, or<br>
could be a separate website for vulnerability reports), then a way to<br>
make the bug visible/editable to "VMT and all subscribers". That way<br>
people we add to the CC end up being in the ACL without having to play<br>
with Custom Policies. A visual indicator of such bugs would also be nice<br>
(embargoed issues should not be discussed openly, and sometimes it's<br>
hard to remember the thing you are on is one of those restricted issues).<br>
<br>
<br>
We'd probably work around the limitation: Release reporting<br>
------------------------------<u></u><u></u>-----------------------------<br>
<br>
One of the things we use Launchpad for is to produce release pages<br>
listing what features and bugfixes landed in a given release tag. There<br>
is no support for that (at all) in Maniphest. So we'd have to switch to<br>
git-log generated changelogs, but that may not be a crazy thing to do<br>
anyway. Release reporting is quite separate from task tracking,<br>
Launchpad just accidentally did both.<br>
<br>
<br>
Hope this helps,<br>
<br>
--<br>
Thierry Carrez (ttx)<br>
<br>
______________________________<u></u><u></u>_________________<br>
OpenStack-Infra mailing list<br>
<a href="mailto:OpenStack-Infra@lists.openstack.org" target="_blank">OpenStack-Infra@lists.<u></u>openstac<u></u>k.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra" target="_blank">http://lists.openstack.org/<u></u>cgi<u></u>-bin/mailman/listinfo/<u></u>openstac<u></u>k-infra</a><br>
</blockquote></div></div>