Hi Krinkle,
I think you've raised some valid points, however, you've missed a couple of
details that are relevant. I'll try to fill in the details so that we can
get a better vision of what the workflow looks like with Differential. Rest
assured, those of us who advocate for using Differential do not want to
break your workflow, or anyone else's. There will be some changes for sure
but we've been working extremely hard to address everyone's concerns for
many months and the only reason that concerns have not been addressed is
because we weren't aware of them or we haven't gotten to them yet.
I'll address each of your major points inline below the quoted text:
On Mon, May 9, 2016 at 1:26 PM, Krinkle <krinklemail(a)gmail.com> wrote:
I apologise if some of the below does in fact exist,
I'd gladly find out!
There are three major parts of my workflow as project maintainer and
contributor that I find lacking in Differential right now and are strong
reason for me to discourage anyone from migrating to it. In addition,
projects that have already migrated are essentially non-existent and blind
to my workflow as a result. I've tried but even if I accept loss in
productivity, I can't even find a workaround for these.
1. Casual notifications about new patches and merged commits (IRC
notifications). -
https://phabricator.wikimedia.org/T116330
If you follow the trail of blockers on that task you end up at
https://phabricator.wikimedia.org/T123417 which is assigned to me and will
be addressed. This will be a small amount of work and it just hasn't
happened yet because it hasn't been the highest priority, especially when
people still regard migration to Differential as "premature."
2. Discover pending patches.
While Diffusion is a fine repo browser, it appears to lack any link back to
Differential. Even when manually going to Differential, it doesn't appear
to be any concept of "repo". It only has a global concept of "diff"
and
"reviewer" (e.g. you can list diffs for review, and your own open diffs).
Unlike Maniphest (which has a concept of projects that have their own pages
with useful outgoing links). There is no list of projects with a link to
see a project's patches. This unlike Gerrit or GitHub where projects are
linked to searches for open patches or open pull-requests. This makes it
very non-transparent for potential consumers of our code, and casual
contributors to find out about open patches. This is an important indicator
for developers to determine the health of a project. It's also an easy
way-in to for new reviewers, and an important interface for project
maintainers to easily list open patches from time to time. Without this, I
expect our code review habits to become even worse than they already are.
https://phabricator.wikimedia.org/differential/ (no projects listed) ->
https://phabricator.wikimedia.org/differential/query/all/ (no repos named
alongside the diffs) ->
https://phabricator.wikimedia.org/D229 (links to
diffusion) ->
https://phabricator.wikimedia.org/diffusion/GOJR/ (no link
to
query to differential).
If I see this correctly, there is simply no way to naturally get to a list
of open patches of a project.
This is a valid concern and I think Differential really is lacking in ways
to browse open patches, however, I think you've missed some critical
details.
1.
https://phabricator.wikimedia.org/differential/query/advanced/ gives
you a way to query by project tags
2. Phabricator is almost completely organized around tasks. You can add
a differential revision to a task and the final commit also gets attached
to the task. The way to browse units of work is by searching maniphest,
not searching differential or diffusion.
3. Phabricator does not consider 'one repository' to be equal to 'one
project' and there is a tool specifically designed for organizing
repositories in to larger units called 'packages' - that tool is
https://phabricator.wikimedia.org/owners/ by combining owners with
herald rules you can get granular notifications of patches submitted in
your area of interest/expertise/responsibility. Not only is this granular
but it's automated - appropriate reviewers get added automatically to
patches that affect the specific code that they are qualified to review.
After you've been added as a reviewer then revisions show up in
Differential and there is visibility into new patches as well as "stale"
patches which are blocking others and have been waiting for some
(configurable) amount of time.
4. Differential links to 'recent similar revisions' on the differential
revision page:
https://phabricator.wikimedia.org/D224
So while I agree that diffusion should really have better integration with
differential, and differential browsing is less than perfect, I disagree
with the statement that there is no way to "naturally get to a list of open
patches of a project"
You rightly point out that Differential doesn't integrate with Projects
nearly as well as it should. I would propose a few changes to improve the
situation:
1. Show projects on differential search results
2. Show Differential revisions on Diffusion repository pages
3. Show Differential revisions on Project profile pages. Most obvious place
would be right above 'recent activity' on
https://phabricator.wikimedia.org/project/profile/1449/ or perhaps on a
separate panel since some projects will probably have a lot of open patches.
3. Notification about new patches and merged commits.
There is appears to be no way to subscribe to a repo (e.g. as a maintainer
of that repo) so that I may be notified of new diffs and/or landed commits.
This is worse due to #2, which would've been a workaround (albeit a costly
one, due to pull:N vs push:1).
Totally untrue. That's what owners is for. See point 3 in my response to
your second concern. Owners (
https://phabricator.wikimedia.org/owners/)
does exactly what you want. Once you create a package, phabricator notifies
you about new diffs and commits, With it's configurable down to the
filesystem level, so you can be notified about changes to specific
sub-trees within specific repositories, or groups of repositories.
In addition to these workflow concerns, there is also
Continuous
integration of course. But that's a separate issue.
Continuous integration is a concern that has been thoroughly addressed.
Differential and Jenkins work well together. Phabricator also has
harbormaster which could theoretically replace jenkins in the long term,
however, we already have a whole lot invested in our existing Jenkins setup
and it doesn't seem wise to abandon all of that without a clear reason to
do so.
I'm bringing up these concerns now because
contrary to what I expected,
Differential is being adopted by quite a few repos now despite it being
premature.
The sooner the better! We can't address concerns if we haven't heard them.
So while I totally sympathize with your concerns, I disagree that it's
premature to start using Differential. We can't work out the kinks without
having experience using the tool and the best way to move forward is to do
it.