Moving bugs to Phabricator

[Daniel Stone]

Hi,

On 3 February 2016 at 20:27, Bryce Harrington <bryce at osg.samsung.com> wrote:
> On Wed, Feb 03, 2016 at 12:25:26PM +0000, Daniel Stone wrote:
>> On 2 February 2016 at 20:28, Bill Spitzak <spitzak at gmail.com> wrote:
>> The workboard columns aren't fixed in the current single-column
>> format: depending on what works best, we could use any combination of
>> one column per release, status-based columns (WIP / mid-bikeshed /
>> etc), or anything really.
>
> Does/can it have a tabulated view with various fields shown (like
> whether patches are attached, number of comments, etc.)?

Not by default, no. We can fairly easily modify the workboard view
show not only what patches are but also their status (i.e. that the
patches have all passed review/CI successfully), and this is quite
high on my list of things to do, but I don't know of a column-based
view like that, though it is doable. Note that Bugzilla doesn't do
these either ...

>> Also, you can make more general (and more advanced) queries from
>> https://phabricator.freedesktop.org/maniphest/.
>>
>> Would be interested to hear some more feedback from people!
>
> I'm with zmike that if the phabs have high barriers of access, I'm
> uncertain it'll adequately replace bugzilla.

Of course. I don't have any insight into how the Enlightenment
instance is configured; my guess is that the default permissions are
too restrictive, and people frequently forget to release them. The
default policy for everything on the fd.o instance is that the public
can view anything without a login, and users can edit everything by
default - so, same as Bugzilla, and most Gerrit installations. I also
did a manual sweep[0]

> It might also be worthwhile to examine the email interface - in other
> projects I've found phab a bit spammy with state change emails.

Yes, I totally agree. The fd.o instance runs with a custom setup which
vastly reduces the number of emails it sends out, but if it's found to
be too spammy in practice, we can very easily tune that back down.

> The command line interface is probably what I would end up using the
> most though.  I know phab has one but haven't used it much.

A couple, yeah. Most everything is exported through a REST/JSON API,
which you can use through arc's call-conduit method:
strictly:~% echo '{ "task_id": 13 }' | arc call-conduit maniphest.info
{"error":null,"errorMessage":null,"response":{"id":"13","phid":"PHID-TASK-vujkuscummfkq3lsrwb7","authorPHID":"PHID-USER-s2ikqzrymjqb2qfwl75z","ownerPHID":"PHID-USER-yqp36qqawguh3f3nst6i","ccPHIDs":["PHID-USER-rdxdcgyjcdncrn6vsazu","PHID-USER-hl5rh4ykug6gxloqip24","PHID-USER-uvp7jfgq5ue7jpcweruo","PHID-USER-dw7nrj2kcnfsin3hs2ep","PHID-USER-yqp36qqawguh3f3nst6i","PHID-USER-s2ikqzrymjqb2qfwl75z"],"status":"open","statusName":"Open","isClosed":false,"priority":"High","priorityColor":"ccu-a-bit-red","title":"dmabuf
import support","description":"Add a new protocol which supports
importing dmabuf file descriptors as buffers, including multi-planar
formats such as YUV.\n\n(How multi-planar support actually works with
EGL in the absence of TEXTURE_EXTERNAL_OES support is an open
question.)","projectPHIDs":["PHID-PROJ-3kgwzw5rmqaxdbm3zj6g"],"uri":"https:\/\/phabricator.freedesktop.org\/T13","auxiliary":{"std:maniphest:git:uri-branch":null},"objectName":"T13","dateCreated":"1423238257","dateModified":"1454593834","dependsOnTaskPHIDs":[]}}

> I seem to
> recall being frustrated by it but don't remember why; like it was
> squashing my patches or something.  Maybe it can be tuned though.

Yes, using 'arc diff' by default will do that; it's designed for
different workflows. But again, as it has a stable external API, we
can develop our own tooling, in the form of git-phab:
http://cgit.freedesktop.org/git-phab/tree/README

This is designed to take a series of patches, upload them individually
to Differential for review, and attach them to a tracker task. You can
see an example of it in action with
https://phabricator.freedesktop.org/T13

I definitely wouldn't propose it if it had such gaping flaws as not
being able to support multiple patches in a set. It's not perfect, but
on the other hand, it's an improvement on Bugzilla, the code review
seems roughly on par with something like Gerrit, and having not only
the two integrated, but also the ability to link to CI for automatic
checks on code proposed for review, makes it quite powerful. Having a
really stable and solid data model with first-class extensions built
in also makes it really attractive, because it makes it much more
malleable than something like Bugzilla, and gives us the ability to
have much better linkage than having separate tools which share no
data.

Cheers,
Daniel

[0]: With a small script; Phabricator's data model is such that it
exports objects rather than having you bash the database directly.
This alone makes it infinitely more extensible, flexible, and sound
than something like Bugzilla. They really care about the data model
upstream, and one of their guiding principles is that the core data
model should be solid enough that extending Phabricator through custom
hooks or applications is quite bulletproof. That to me is one of the
most attractive things about it.