I don't think this made it to 100% of callsites but we have reasonable saturation now, are populating it on newer tasks, and haven't hit any issues where this information would be useful in a long time. I'm just going to call this resolved-enough, we can add more of them if we're still missing some as needs arise.

This was a very long time ago, but I think the root cause of whatever was happening was really conflated with some other issue.

I believe D11874 covers the last of this for Git.

It's not causing enough pain for me to jump up and down about this. Thank you for clarifying @epriestley!

This would make Calendar actually useful for us.

We don't currently tell CircleCI which user to run as explicitly -- I'd guess the user the build runs as is determined by the token we use.

I'm merging this into T10751, which is a cleaner followup without two years of outdated history. The goals remain the same.

Just as a data point, the Wikimedia community is a user of git's .mailmap support for our repositories as it gives repository owners/committers a way to clean things up unilaterally (instead of pushing the work on the individual authors who may or may not be contactable anymore). I was reminded of this after seeing a recent cleanup .mailmap commit in our operations/puppet repository: https://gerrit.wikimedia.org/r/#/c/282405/

Also, to directly answer your question, the existence of Schrodinbugs and Heisenbugs suggest otherwise. ^,^

Hi Chad, I had to try commenting on a file to test if a bug on my server was present here as well. It is - see T10750: Cannot Edit Comment on Files.

If a bug is not validated, does it truly exist?

(This is a test, to validate a bug.)

That's my expectation too -- the user cycles their "2012 Hackathon Winner" badge out for "2013 Easter Egg Finder" once they get bored of it, so badges are always fresh and lookin' fly.

I expect every user to have millions of participation badges. Yet they'll have to select just two to prominently display.

I'm struggling with how to think about the 'temporal' nature of some peer awards that might fit badges. For example, I'd like to give the team that won the popular vote at a hackathon, but it would not feel so special if after a year "everyone" had an Epic badge displayed all the time. I'm thinking more "you get celebrated for a month" and less "list of all the typos I found 3 year ago".

Interesting. Time to update my bot. Thanks!

See also T5462

I have build kind of thing out myself, using polling to check what revisions are open, then diff my list of "envs / build jobs" that I have running and then make the two line up. It would nice if it could be event based and triggered by herald.

That's exactly what I needed.
I thought I could create one global rule to do this. But if I get this right, I have to create multiple rules for every single project to add as subscriber :D

Any MantisBT -> Phabricator migration scripts ?

You're welcome to make a diff and say, share it as a paste, but we're not in the habit of pulling in workarounds, and generally focus on the longterm solution. T5873 literally touches every application in Phabricator, it's more a container task than anything else. We've been rolling these updates out as we're working in adjacent areas.

[darkness intensifies]

As T5873 has been open for a year and a half, and isn't on the immediate roadmap, is there perhaps a way to update getrevisioncomments to expose some more info, so that bots etc can access it?
Would people be open to me making a diff to that end?

See also T5381: Provide RSS feed of changelog (I'm not sure if identical/mergeable)

There was some unrelated discussion, but I think the original idea was to have a dashboard panel which is only this (panel on its own):

You can panelize a Countdown query now? What's left here? https://secure.phabricator.com/W456

Dashboards need too much work to make this straightforward.

@kravitz: You are changing the cli php.ini but NOT the apache2 one.