Page MenuHomePhabricator

sgrimm (Steven Grimm)
User

Projects

User does not belong to any projects.

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Thursday

  • Clear sailing ahead.

User Details

User Since
Apr 28 2011, 6:55 PM (553 w, 5 d)
Availability
Available

Recent Activity

Apr 21 2017

sgrimm added a comment to T12410: Cycle Time and Lead Time Reports.

It would be useful to extend this concept to the lifecycles of other Phabricator objects, not just Maniphest tasks. For example, people on my team have sometimes wanted to see a histogram of how long it takes Differential diffs to get reviewed, especially if we can break it down by author and/or reviewer.

Apr 21 2017, 11:01 PM · Feature Request

Nov 1 2016

sgrimm added a comment to T2543: Add a formal "Draft" / "Not Yet Ready for Review" state to Differential.

I'm specifically interested in the arc diff --try part of this and would want that to be the configurable as the default behavior. For an installation that's using things like CircleCI integration to run tests asynchronously on a build server, it seems very plausible that reviewers will sometimes fail to notice that tests haven't finished running yet, which will lead to people landing broken code.

Nov 1 2016, 8:23 PM · Customer Impact, Restricted Project, Restricted Project, Prioritized, Differential

Jul 18 2016

sgrimm added a comment to T11343: Generate default "Depends on" line in commit message when multiple diffs are stacked.

Obviously I can implement this myself locally, but if it's a lousy idea for whatever reason, I'm hoping filing this request will cause someone to warn me off it.

Jul 18 2016, 10:27 PM · Differential, Arcanist, Feature Request
sgrimm created T11343: Generate default "Depends on" line in commit message when multiple diffs are stacked.
Jul 18 2016, 10:26 PM · Differential, Arcanist, Feature Request

Aug 20 2015

sgrimm added a comment to T9223: Allow `arc diff` to run a build step like `gradle` first, then read lint and unit messages from the output.

By default, and the default is used in basically every project I've seen, the "run tests" command in Maven will do a build first. An analogous Makefile would be something like

Aug 20 2015, 4:25 PM · Unit, Arcanist
sgrimm added a comment to T9223: Allow `arc diff` to run a build step like `gradle` first, then read lint and unit messages from the output.

By "One option that would work" I meant, "One option that would work in a world where a single command can be both a linter and a tester," in case that wasn't clear.

Aug 20 2015, 3:54 PM · Unit, Arcanist
sgrimm added a comment to T9223: Allow `arc diff` to run a build step like `gradle` first, then read lint and unit messages from the output.

That pattern is definitely possible, but the "make or whatever" step can take a noticeable amount of time on a complex project even when there's nothing to build, so you're kind of faced with choosing between "minimize time to lint errors" and "minimize total time for a successful diff submission."

Aug 20 2015, 3:52 PM · Unit, Arcanist
sgrimm added a comment to T9223: Allow `arc diff` to run a build step like `gradle` first, then read lint and unit messages from the output.

I've attached

just so we have something concrete to talk about. Right now this is sitting in our source repository and we load and run it via .arcconfig entries as you'd expect. It is much closer to a "run everything" implementation than a highly selective one, though it is able to deal with repositories that have multiple Java projects (where a "project" is indicated by the presence of a pom.xml file) and will only run tests in projects that have changes. So for source bases that have code for multiple server components, it'll be at least somewhat selective. And if the pending change list has no changes in any Java projects, it won't run anything. (Obviously this has the potential to be wrong if, e.g., a change modifies data files that affect a test, but it's likely to be right in cases like a repository that has both front-end and back-end code.)

Aug 20 2015, 2:35 PM · Unit, Arcanist

Aug 19 2015

sgrimm created T9223: Allow `arc diff` to run a build step like `gradle` first, then read lint and unit messages from the output.
Aug 19 2015, 10:36 PM · Unit, Arcanist

May 8 2014

sgrimm added a comment to T4997: App naming is a barrier to entry.

Strike that last comment about tooltips; I see they're already there.

May 8 2014, 7:08 PM
sgrimm created T4997: App naming is a barrier to entry.
May 8 2014, 6:55 PM

Feb 28 2014

sgrimm added a comment to T4482: Document one or two reasonable workflows for Github repositories.

For what it's worth, here's a little intro document I wrote for the company I'm helping out. Company-specific stuff replaced with XXX here to make this easier to reuse if anyone wants to reuse it. If you don't mind, I'll also copy-and-paste a lot of what you wrote. They are a pretty small shop with just a few generalist developers of more or less equal responsibility, hence the recommendation for everyone to add Herald rules to make themselves review everything.

Feb 28 2014, 10:31 PM · Guides, GitHub, Documentation
sgrimm added a comment to T4482: Document one or two reasonable workflows for Github repositories.

My approach to answering these questions is to basically say, "Once you're using Phabricator, Github becomes a dumb git repository server and you should just completely ignore its UI." I hope that's actually true.

Feb 28 2014, 9:36 AM · Guides, GitHub, Documentation
sgrimm raised the priority of T4482: Document one or two reasonable workflows for Github repositories from to Needs Triage.
Feb 28 2014, 9:31 AM · Guides, GitHub, Documentation