Page MenuHomePhabricator

lvital (Lionel Vital)
User

Projects

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Thursday

  • Clear sailing ahead.

User Details

User Since
Jan 9 2016, 1:02 AM (460 w, 3 d)
Availability
Available

Recent Activity

Sep 27 2017

lvital updated subscribers of T11343: Generate default "Depends on" line in commit message when multiple diffs are stacked.
Sep 27 2017, 6:30 PM · Differential, Arcanist, Feature Request

Aug 29 2017

lvital accepted D18493: Make legacy revision statuses from "differential.query" have type "string" again.
Aug 29 2017, 8:04 PM

Aug 10 2017

lvital accepted D18385: Make the "Requested Changes to Prior Diff" reviewer icon red, not bluegrey.

bluemyself

Aug 10 2017, 6:03 PM

Jul 5 2017

lvital added a comment to D15926: Show reviewer status and authority on revision list view.

Yeah, I could see that being a not very elegant path to go down. I guess it depends on how difficult it is to implement f(g(h())). If it is a deep rabbit hole, then it's probably best to just fill in a few specific use cases that we think are compelling, e.g. exactviewer() (assuming you think it's useful).

Jul 5 2017, 8:57 PM

Jun 29 2017

lvital added a comment to D15926: Show reviewer status and authority on revision list view.

Thanks for the feedback. There is definitely a problem in general where people are added to too many reviews, but it's generally due to being part of too many owner packages. We have been encouraging teams to prune their ownership to minimize gatekeeping, but it's still helpful to have targeted dashboards.

Jun 29 2017, 11:03 PM

Jun 27 2017

lvital added a comment to D15926: Show reviewer status and authority on revision list view.

Particularly, the use cases I think this is most valuable for are:

  • Distinguish between things in your "Must Review" bucket and "Should Review" bucket that are there because you have to review them, vs there because some package or project you have authority over has to review them ("Is this for me personally, or just a platform eng revision?")
  • Show which projects/packages you have authority over ("Why do I have to review this?").
  • Show status of projects/packages ("Why is this blocked on me?").
Jun 27 2017, 12:00 AM

Jun 14 2017

lvital awarded T12844: MetaMTA worker can win a race against MTAMail despite both being inserted in the same transaction, because they aren't actually inserted in the same transaction a Burninate token.
Jun 14 2017, 7:02 PM · Daemons, Mail, Restricted Project, Bug Report

Jun 7 2017

lvital added a comment to T12804: Diffusion pre-redesign UI feedback (June 2017).
In T12804#226416, @chad wrote:

I don't believe moving buttons and changing layout will affect page load speed. If you have real performance issues, we should address those in another task.

Jun 7 2017, 10:42 PM · Diffusion, Design
lvital added a comment to T12804: Diffusion pre-redesign UI feedback (June 2017).

I think the majority of issues I (and many others at Twitter) run into is due to performance / slow page loads. If there is anything in the UI that could be minimized / simplified to speed up page loads, that would be really helpful. However, I imagine that performance is mainly a back-end issue (and probably our instance's fault in some ways).

Jun 7 2017, 10:31 PM · Diffusion, Design

Jun 1 2017

lvital accepted D18064: Make Owners behavior when multiple packages own the same path with different dominion rules more consistent.
Jun 1 2017, 9:28 PM
lvital added a comment to T12789: Confirm/remedy issues with duplicate Owners paths.

@epriestley yes, the tested owner packages were both weak dominion. Sorry for not mentioning that earlier. You've explained the issue perfectly as far as I can tell. The changes you have planned make a lot more sense than the current behavior and should fix the issues we were seeing. Thank you!

Jun 1 2017, 5:48 PM · Owners, Restricted Project, Bug Report, Customer Impact

May 25 2017

lvital added a comment to T12758: Consider a "Check All" control for reviewer checkbox lists.

That could work too. Perhaps a box of donuts instead though.

May 25 2017, 10:12 PM · Customer Impact, Owners, Restricted Project, Differential
lvital added a comment to T12758: Consider a "Check All" control for reviewer checkbox lists.

Another solution I could imagine is to add a distinct action, other than "Accept", which works like the old "Accept" did, i.e. "Accept for all reviewers I have authority to accept for", say "Accept Magnanimously".

I'm hesitant to pursue this today because I want to be cautious about adding too many actions, and I think other changes may add more valuable actions ("Accept Next Update", draft-state actions from T2543, etc). This action would probably be fine today in isolation since the dropdown doesn't feel too cluttered right now, but if we added it I think it might be the least valuable / least frequently used action in a list that is starting to look pretty bloated six months from now.

(I think it's also somewhat hard to pick a 2-3 word phrase which clearly describes how this potential action differs from "Accept" -- I can't come up with anything good offhand.)

May 25 2017, 9:26 PM · Customer Impact, Owners, Restricted Project, Differential
lvital accepted D18019: Don't consider accepting on behalf of valid-but-accepted reviewers to be a validation error.
May 25 2017, 9:22 PM
lvital added a comment to T12757: Multiple reviewers can race one another to accept on behalf of packages and get a poor UX.

Yep, those repro steps look right to me.

May 25 2017, 7:22 PM · Customer Impact, Restricted Project, Differential
lvital added a comment to T12758: Consider a "Check All" control for reviewer checkbox lists.

FWIW, a check-all box is what we had in mind.

May 25 2017, 7:22 PM · Customer Impact, Owners, Restricted Project, Differential

Apr 11 2017

lvital accepted D17652: When reviewing, always show "Accept" checkboxes for packages/projects, even if there's only one checkbox.
Apr 11 2017, 12:22 AM
lvital closed T12533: Reducing "Accept" action to not render a checkbox when only one package or project would be accepted is perhaps more confusing than not as Invalid.

Thanks, closing this one!

Apr 11 2017, 12:07 AM · Owners, Restricted Project, Bug Report
lvital added a comment to T12533: Reducing "Accept" action to not render a checkbox when only one package or project would be accepted is perhaps more confusing than not.

Or I guess, you* can close this since I can't. Whoops.

Apr 11 2017, 12:03 AM · Owners, Restricted Project, Bug Report
lvital added a comment to T12533: Reducing "Accept" action to not render a checkbox when only one package or project would be accepted is perhaps more confusing than not.

Scratch that, you're right @epriestley . We just got confused during the workflow and didn't realize jmeador previously accepted.

Apr 11 2017, 12:02 AM · Owners, Restricted Project, Bug Report

Apr 10 2017

lvital added a comment to T12533: Reducing "Accept" action to not render a checkbox when only one package or project would be accepted is perhaps more confusing than not.

Whoops, I think I may have totally fudged the screenshots. Let me try to reproduce with proper screenshots.

Apr 10 2017, 11:39 PM · Owners, Restricted Project, Bug Report
lvital created T12533: Reducing "Accept" action to not render a checkbox when only one package or project would be accepted is perhaps more confusing than not.
Apr 10 2017, 11:06 PM · Owners, Restricted Project, Bug Report

Apr 6 2017

lvital added a comment to T12272: Allow users to accept on behalf of packages they control a containing package for.

Just tested, works great. Thanks for the quick fix!

Apr 6 2017, 10:13 PM · Owners, Audit, Restricted Project, Differential
lvital accepted D17634: Fix scope of "Accept" when you don't check all the "Force Accept" boxes.
Apr 6 2017, 10:02 PM
lvital added a comment to D17633: Provide a "Reviewers" attachment to "differential.revision.search".

The meaning of isCurrent was "is this reviewer relevant for state calculations against the current state of the revision", which is kind of involved.

For example, a revision with one user who has "Rejected" is normally in state "Needs Revision", until the next update, but not if the author does "Request Review". When they do, they internally void the outstanding rejects and make them noncurrent.

But current-ness depends on a lot of internal state stuff and on differential.sticky-accept and I think it's ultimately too wrapped up in state calculation to be of much use. At best, you could use it to render "Accepted Current Diff" vs "Accepted Older Diff" some of the time, but it doesn't always mean that and there's no real human-readable label for what it does mean.

Apr 6 2017, 9:49 PM
lvital accepted D17633: Provide a "Reviewers" attachment to "differential.revision.search".

noidea

Apr 6 2017, 9:40 PM
lvital added a comment to T12272: Allow users to accept on behalf of packages they control a containing package for.

No prob! If it helps:

Apr 6 2017, 8:50 PM · Owners, Audit, Restricted Project, Differential
lvital added a comment to T12272: Allow users to accept on behalf of packages they control a containing package for.

Not sure if this is a known bug / missing feature, but FYI just in case...

Apr 6 2017, 8:46 PM · Owners, Audit, Restricted Project, Differential

Mar 16 2017

lvital awarded T12372: Long list of reviewers breaks to: field when metamta.one-mail-per-recipient set to false a Burninate token.
Mar 16 2017, 5:58 PM · Mail, Bug Report

Mar 13 2017

lvital added a comment to T12372: Long list of reviewers breaks to: field when metamta.one-mail-per-recipient set to false.

Great, thanks for testing it! We'll upstream that and I'll file something to put a longer-term fix in place.

"witter.com" <fakeemailtest+163@t>

ah yes this is my very favorite email address of all

Mar 13 2017, 10:56 PM · Mail, Bug Report
lvital added a comment to T12372: Long list of reviewers breaks to: field when metamta.one-mail-per-recipient set to false.

Confirming that the patch above works (tested using send-test --to)!

Mar 13 2017, 10:43 PM · Mail, Bug Report

Mar 10 2017

lvital added a comment to T12372: Long list of reviewers breaks to: field when metamta.one-mail-per-recipient set to false.

Great, thank you!

Mar 10 2017, 10:55 PM · Mail, Bug Report
lvital accepted D17489: Allow "bin/mail send-test" to accept raw email addresses via "--to".
Mar 10 2017, 10:49 PM
lvital added a comment to T12372: Long list of reviewers breaks to: field when metamta.one-mail-per-recipient set to false.

Sounds reasonable to me.

Mar 10 2017, 10:45 PM · Mail, Bug Report
lvital added a comment to T12372: Long list of reviewers breaks to: field when metamta.one-mail-per-recipient set to false.

Any suggestions to test this on staging without mass emailing everyone / patching prod? I am trying to test this on staging with bin/mail show-outbound --id xxxx (staging has mail disabled), but the recipients / To: list look fine with or without the patch.

Mar 10 2017, 10:23 PM · Mail, Bug Report

Mar 9 2017

lvital added a comment to T12372: Long list of reviewers breaks to: field when metamta.one-mail-per-recipient set to false.

Thanks for the quick fix and the huge amount of detail under the hood, we'll give that patch a shot!

Mar 9 2017, 6:57 PM · Mail, Bug Report
lvital updated subscribers of T12372: Long list of reviewers breaks to: field when metamta.one-mail-per-recipient set to false.
Mar 9 2017, 12:55 AM · Mail, Bug Report
lvital created T12372: Long list of reviewers breaks to: field when metamta.one-mail-per-recipient set to false.
Mar 9 2017, 12:50 AM · Mail, Bug Report

Feb 17 2017

lvital updated subscribers of T12272: Allow users to accept on behalf of packages they control a containing package for.
Feb 17 2017, 7:52 PM · Owners, Audit, Restricted Project, Differential
lvital added a comment to T12272: Allow users to accept on behalf of packages they control a containing package for.

As far as "opt-in", are you mostly concerned about performance?

Feb 17 2017, 6:46 PM · Owners, Audit, Restricted Project, Differential
lvital added a comment to T12272: Allow users to accept on behalf of packages they control a containing package for.
NOTE: Since packages do not own paths exclusively, any user can create a package on / of every repository and be allowed to force-accept every package review because their "everything" package is now a containing package for all other packages. However, they could already just remove the reviewers, so I don't think this is important. We could add options to Owners (e.g., an optional whitelist of "Stronger" packages) or something to prevent this, but I don't plan to do this. Just fire anyone abusing it.
Feb 17 2017, 5:57 PM · Owners, Audit, Restricted Project, Differential

Aug 9 2016

lvital updated subscribers of T11450: Distinguish between issue and non-issue inline comments.

Responding to as much as I can. @eadler @scode feel free to chime in / correct anything below.

Aug 9 2016, 10:13 PM · Inline Comments, Restricted Project, Feature Request
lvital updated the task description for T11451: Threaded comments.
Aug 9 2016, 4:47 PM · Restricted Project, Feature Request
lvital created T11451: Threaded comments.
Aug 9 2016, 4:46 PM · Restricted Project, Feature Request
lvital created T11450: Distinguish between issue and non-issue inline comments.
Aug 9 2016, 4:44 PM · Inline Comments, Restricted Project, Feature Request

May 9 2016

lvital updated the task description for T10939: Support for OWNERS files.
May 9 2016, 5:09 PM · Prioritized, Restricted Project, Owners