Hrrm, let me see if I can reproduce anything like that, that's totally bizarre to me.

Hmm, weird. Can you show me the EXPLAIN SELECT ... for that?

Maybe we could add a "you weren't a recipient in the first place" reason which has priority over the other reasons, and make the text on the page more clear. Or just remove "Outbox" completely, I'm not sure it's really useful.

That is, "Delivery" is "delivery to you, the viewer". Maybe that's what's unclear?

The "Delivery" tab is specific to the viewer, not the mail. There's no way to see see why mail was or wasn't delivered to other users.

223663 is you adding a comment to Conpherence.
184911 is you moving a task on a workboard.
219192 is you attaching a task to a revision.

I can't actually see them, let me go pull up the console.

In all of them, I'm the actor, but they specify "Self Mail" as the (a) reason for voiding.
I do have "self mail" disabled, so it might be taking that?

D15459 is a partial fix here. Here's an "after":

D15458 is not a retroactive fix, but new comments made after that change should no longer be separable.

That key seems like it's probably not great for the OR changeType part of the query. If you still have the table handy and playing with it doesn't take an unreasonably huge amount of time, is this better?

getEnableCoverage() returns three values:

I'm going to figure out what the state of large PUTs

Sorry, I'm still not understanding what specific change you're concerned about. Isn't the information in the same place -- with the same behavior -- as it was before?

I miss the create date being easily visible.

I added you to Community so you should have access now.

To clarify, you're expecting the error message to disappear immediately, before you submit the form?

You can sort of do this like this:

This may make sense to at least lightly entangle with T4752, which overlaps in some ways.

To do an integrity check, it looks like we have to compute the Git hash ourselves.

As a general preface, this stuff makes me a little uneasy about LFS in its current state:

D15454 changes the wording to:

We should probably change the text on "placed up for grabs" to "unassigned from X". I don't think we use that term anywhere else nowadays, either.

The "Issue Events API" appears to provide the remaining events in a different format with different rules. It does not provide any duplicate events, so, e.g., one API retrieves issues being created and commented on while a different API retrieves labels, milestones, etc., except that both report opens and closes, I think. Anyway, seems mostly workable.

Alright, so here's the first real issue. Here's what I did on GitHub:

is there a way to add subscribers via lint rules?

Primarily, I'm just hesitant to make changes where you upgrade and previously-private stuff becomes public, since I think that's a terrifying behavior in the general case and maybe even worse than destroying data.

To provide a little context, I suspect we'll just make personal rules publicly visible. Long ago, transaction records were not as explicit or complete as they are today and you could sort of hide your "keep an eye on the suspicious interns" rules a little better, so this policy behavior wasn't totally silly, but it's almost impossible to actually hide any information now.

Is this rule a lint-like rule, in the vein of T7617? See also T10523 for discussion of lint-like rules.

Yeah, I think the existing "Edit" page should really be more like the "Manage" page in Projects that anyone who can see the repository can see.

If anyone else set up a cron job or similar to keep a staging area with a fresh master, you should be able to throw it away after users upgrade past T10509. That task has some details.

Aha! That makes sense, thanks for digging into it!

If the motivation is primarily social, you might be able to use a social permission:

Part of the pathway forward here may also be to reduce the prominence of subprojects in typeaheads/lists, or reduce it conditionally or something.

This is currently intended, although I think it's not out of the question that we might relax it or otherwise take another look at it.

Awesome, thanks!

This is probably at least somewhat reasonable, and we do something vaguely similar in the Maniphest list view.

I'm a little worried that doesn't make for a great out of the box or support experience since almost anything interesting will require extensions, but that is basically the case anyway today.

Is it reasonable for this value to be part of the job name?

Maybe this is a better question: if someone else files a similar task saying that the repository projects or date created or full list of tags or default branch would help them glue to Jenkins/Travis/Hudson, when should I say "yes" or "no"?

I don't want to add upstream build variables in every case where they'd make things more convenient for someone, since that could get out of hand quickly.

how to make the job smart enough to call back

Yeah, my expectation is that whatever's on the Jenkins side needs to know about Phabricator, because it needs to call harbormaster.sendmessage to report results when it's done. So it seems like the job has to be some-harbormaster-aware-build, and like it should be able to look up the repository name without undue work, as it already needs to know how to call Conduit.

Why is the approach used by Uber's Jenkins/Phabricator Plugin (which does not require repository.name) unsuitable in your situation?

Since that sounds possibly plausible, I'll confirm that timeouts end up looking like this in the UI, and repurpose this for "make timeouts readable to humans" if they do. I can dig into it some more if that turns out to be a dead end.

You control that API though, right? And could conceivably expose /harbormaster/job/{repository-phid}/ or whatever?