On 04/03/2015 11:48 AM, Monty Taylor wrote: > On 04/03/2015 11:16 AM, Thierry Carrez wrote: >> Monty Taylor wrote: >>> As a follow up to my previous email about thinking about ceasing to use >>> storyboard, I have done some work towards investigating using phabricator. >>> [...] >> >> For the record, I'll repost some of the analysis I did for mordred on this. >> >> >> Main blocker: Ability to track tasks across projects/branches >> ------------------------------------------------------------- >> >> One of the main features we need from a task tracker in OpenStack is the >> ability to track the completion of tasks across projects and branches. >> That affects vulnerability management, bug backports, and generally >> cross-project work. The fact that Launchpad has a limitation there (on >> the number of tasks it supports before timeouting) is issue #2 with LP. >> The problem is stated once, then a number of tasks affecting different >> groups are created, and the issue is closed when the last task is completed. >> >> In Maniphest as it stands, that would translate into one of those: >> >> 1- Create a single task that affects multiple "projects" >> 2- Create a main task and multiple subtasks, one for each "project" >> >> The main issue with (1) is that you can't track partial completion (i.e. >> which groups have completed their task and which haven't), which is the >> main goal of using a common task tracker. >> >> The main issue with (2) is that it's difficult to see what groups are >> affected from the "main" task (since it only lists task names), and the >> main task is not autoclosed when the last subtask is closed (requiring >> manual intervention). > > I think 2 is the way phabricator expects this to be modeled. It's > certainly different, but it also gives us a view of a thing we've NEVER > had that I honestly think might be more useful to more people. If you > look at: > > https://secure.phabricator.com/T1536 > > You can see quite quickly which tasks are done and which are still > blocking this main task from being done. That those aren't broken out by > project there is actually a little nice to me - we are "One Project" > after all. > > Looking at how wikipedia are using the feature as well may be > enlightening. I believe they similarly have multiple projects as well as > multiple vertical efforts. > > In fact, one of the things I particularly like is that it's NOT tied to > repos or branches ... because things like "product management" have > interests that are particularly clunky when we're tied to a thinking > everything is related to a git repository... as is thinking that having > multiple git repositories means multiple bug projects. The mapping is > actually potentially different given the project. > >> In both cases, the UI allows multiple "projects" to apply to a given >> task, which is great for tagging, but not so great when you want to >> track tasks per affected repository and branches. Finally, there is no >> concept of branches -- we would have to create one project for every >> repo/branch combinations. > > I'm not so sure about this. I actually think we could create a "nova" > project and a "stable/kilo" project. Or we may need a nova-kilo - I > don't know - but I think there are some iterations we should investigate. > >> Finally, "projects" have no relationship between them. So even if you >> associated a task to project "openstack/nova--master" you would have to >> also manually associate it to project "nova" (as in openstack/nova + >> openstack/python-novaclient) so that Nova team members could also find >> it there. There is basically no projectgroup concept, which is issue #3 >> we have with Launchpad. >> >> In summary, I think Phabricator's "projects" concept is a (really) neat >> *tagging* system, with associated dashboard and all. > > Yes. It is, in fact, explicitly a tagging system. > >> It's just not meant >> to cover multiple "projects" in the OpenStack sense. Our projects have a >> few properties which make them difficult to emulate with Phabricator's >> "projects": there should be only one per task, they have an affected >> branch (master, juno...), and they are grouped into higher-level >> structures that can be searched and browsed as well. >> >> Phabricator seems to be sized for single separate projects, and it's >> "project" concept is just a way to organize work within that single >> project. It is pretty obvious when you see what happens if you click one >> of their "projects": you end up in a dashboard with one item per bug. >> Imagine clicking openstack/nova and landing on a dashboard with >> thousands of bugs: it's just not meant to be used for that. It is >> excellent for tracking a subset of tasks and organizing them, but not as >> a higher-level structure. >> >> So in order to make it work, we'd need a whole new concept added, let's >> call it "repository". Each repository may have multiple branches >> associated with it. When you create a task, you select a repository and >> a branch (and only one). That field is clearly shown in the task name >> (no need to drill down to the subtask to find which repo/branch is >> actually affected by the task). Clicking on that will bring you to a >> list of bugs affecting that repository. Repositories can be grouped >> arbitrarily into repogroups which let you search and navigate issues in >> a set of repositories, rather than force everyone to rebuild queries to >> find, say, "all infra issues". > > Although I pretty much defer to you in all things related to this and > always have - I'd like to repeat what I said in my other email ... > namely, I think this is very explicitly about not having a perfect > system but realizing that there are always tradeoffs. > > We have, for 5 years, been using Launchpad Blueprints, which have almost > no value other than overhead. So I'm not comparing this to what > storyboard might be in 2 years, I'm comparing it to what we have right now. > >> Then we could encode a rule so that when the last subtask of a repo-less >> task is closed, the parent task is auto-closed. Then that /could/ all >> work for task coordination for OpenStack, although it would be slightly >> less convenient than Launchpad or StoryBoard (which do not require you >> to drill down to update subtasks, and keep the discussion in one single >> place). > > Yes - I think a thing that autocloses parent tasks when all blocking > tasks could be easy enough to accomplish. However, that would undercut > the value of having blocks/blocked-on relationships between issues, > which is a thing we've never had. I'd rather suggest that someone > probably should own the thing we think of as a top-level task instead. > If we auto-close, then as soon as the task I'm working on that is > blocked by another task which is not a sub-task in the launchpad sense > closes, my bug would get closed - which is not the case - I've simply > been waiting on it so that I could work. > >> >> Could do a lot better: CLI/API >> ------------------------------ >> >> One of the main pain points with Launchpad is its partial API. >> Phabricator comes with the "arc" tool, but it is designed to drive the >> DVCS git-like featureset. There is no CLI for Maniphest, only a shortcut >> to make raw Conduit (API) calls. The Conduit API itself looks >> mostly undocumented and (2) "making Conduit more robust isn't currently >> a major project priority because there isn't much demand for it outside >> of internal scripts". > > Since they call out not-much-demand - I betcha that we could get > traction here. Also - there is a python library that I used to interact > with bugs in phabricator. > >> We rely on a lot of scripting to interface with Launchpad, which is why >> a complete and clean API was such a significant part in StoryBoard >> design. It looks like the Maniphest story on APIs is actually worse than >> Launchpad. >> >> >> Could do better: Tracking feature development >> --------------------------------------------- >> >> A feature is a complex task for which you want specific rules to apply >> (like tasks may only affect master branch). It's good to visually >> separate them too, so that feature-frozen period clearly excludes them. >> Communicating the % of feature completion is also valuable information. >> Being able to order subtasks is a nice add too. >> >> Maniphest has no concept of task types, although it could be emulated >> with a "project" (we'd tag all features with a "feature" project), or we >> could use a custom field for that. It doesn't have a concept of feature >> completion status either. Ideally that would be derived from the number >> of completed subtasks, or set by the user on the top task. The absence >> of a story (or task group) might bite us here (since in Maniphest >> everything is a task, and completion only makes sense on a task group). >> Also you can't order subtasks in Maniphest at all. >> >> Not sure how to solve this one, and improvements around feature tracking >> are the #1 reason for StoryBoard to exist. But one could argue that it >> won't be worse than using Launchpad anyway. > > I would argue that we would be substantially improved over launchpad, > given that blueprints is so useless. > >> Could do better: ACLs for Vulnerability management >> -------------------------------------------------- >> >> Vulnerability management is about the ability to file a report that is >> originally only seen by its reporter and a specific team. Then we >> gradually add people to the ACL as we pull them in to help with >> resolution, up to the point where the bug is open. >> >> While Maniphest has task ACL support, it is pretty crude. There seem to >> be no way to encourage people to file security reports privately (they >> have to find out and make use of the "Visible To" and "Editable By" >> dropboxes by themselves). Then there is no way short of defining a >> "Custom policy" for a user to say ("me and the VMT"). Then there is no >> way (short of expanding the custom policy) for the VMT to add >> individuals to the ACL. >> >> For this one to work, we'd need a way to encourage people to file >> vulnerabilities the right way (some sort of task creation template, or >> could be a separate website for vulnerability reports), then a way to >> make the bug visible/editable to "VMT and all subscribers". That way >> people we add to the CC end up being in the ACL without having to play >> with Custom Policies. A visual indicator of such bugs would also be nice >> (embargoed issues should not be discussed openly, and sometimes it's >> hard to remember the thing you are on is one of those restricted issues). > > I'd love to learn how wikimedia is working with this.
http://www.mediawiki.org/wiki/Phabricator/Security tl;dr They have added a security dropdown to task filing that triggers some policy actions. I betcha we could copy theirs. >> >> We'd probably work around the limitation: Release reporting >> ----------------------------------------------------------- >> >> One of the things we use Launchpad for is to produce release pages >> listing what features and bugfixes landed in a given release tag. There >> is no support for that (at all) in Maniphest. So we'd have to switch to >> git-log generated changelogs, but that may not be a crazy thing to do >> anyway. Release reporting is quite separate from task tracking, >> Launchpad just accidentally did both. > > Thanks for diving in! I realize that I'm explicitly requesting that you > think about tools that by definition mean giving up on elements of > design of the thing that you do, and that sucks. I hope that my push > back comes across as an argument that we could potentially rethink a few > things and not fall apart rather than a suggestion that the things you > want in life are somehow invalid. > > > _______________________________________________ > OpenStack-Infra mailing list > OpenStack-Infra@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra > _______________________________________________ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
