@Ajaxs86 you appear to have posted your API token here and should probably revoke it.

Yeah I have a diff incoming, looks like it's working.

This is brittle but it works if your objects all use the native storage.

Yeah, unit messages are stored in a different table.

I'm a corporate user and I love hiding things :(

Related to T11344

I'm trying to figure out if I destroyed our files this weekend by migrating them or by using purge / compress.

Actually....

Ok cool.

I was thinking custom field that just pings a callback url was what I was thinking.

I guess this is customfieldable already, isn't it? There will be weirdness with checking state in the field / the interface doesn't explicitly support it, but I'm pretty sure it's doable.

See edit for clarification.

Is this not a modularizable thing?

It's causing a lot of pain mostly because we don't have good visibility into it happening, and we don't have any good way to react to it once we get close to fully saturated.

(broken wiki links everywhere)

+1 we just discovered this issue and ended up here

final class PhavNoUnitCustomArgument extends ICCustomArcanistArgument {

I emailed evan a "print page" pdf of the ticket off of our install.

14.04

INLINE COMMENTS BRAD

I think that this has only ever happened on Chrome on Ubuntu, and to boot, we've seen client side Ubuntu bugs pop up in the past. (Brad do you remember where?)

• Entirely unset mysql.host
• Configure a master and a replica in cluster.databases
• Go to /config/database/

(not that adding the feature would harm us, just my 2 cents)

We have a particularly opinionated set of developers here (when I say "opinionated", I mean roughly, nobody ever agrees on anything) and we've managed to successfully argue in favor of just using "plan changes" rather than opting for some other intermediary or distinct state. It correctly communicates to reviewers what you should want them to know: you're not done with the revision yet. Far and away the largest reason why this is our accepted workflow, rather than pushing on upstream to implement a "Not Yet Ready for Review" state is very tightly coupled to the entire concept of why Phabricator does review the way it does:

Developers do run the test suite locally if they suspect they probably broke things though, it's not "never", it's just "infrequently".

Yes we use arc unit as the chokepoint for "consistently run unit tests as far as phabricator is concerned", and use the --target flag when harbormaster is running the tests.

Thanks!

We haven't yet enabled, but will be enabling MFA this week.

The best way to describe this request from our perspective is "third party requirement", which falls under your definition of a policy compliance change, mostly.

I'll start doing this, I guess it makes me a little uncomfortable since the first thing I do is typically make sure nothing is broken once the daemons restart, but then again, nothing has ever been broken during a deployment. So maybe I will assume I am as smart as our past deployments have indicated I am, issue the reload, go to sleep, and then check in the morning.

There is no trickery involved in our repository edit field, it might as well be a datasource field.

test

I think that "forking" is the right answer here.

It's not rewriting an existing published branch, we don't permit that, it's just publishing a branch that you've accumulated a bunch of things on as you've been iterating for some period of time. You're not done with it by and stretch of the imagination, and it's been sitting on your machine too long for you to not push it somewhere.

./bin/search index --force --all fixed this,.but i'm confused how some random tasks weren't indexed and some were

Probably a really quick partial remedy to the fallout (not root cause) is just exploring ways to make it super obvious to people that they shouldn't be interacting with disabled accounts.

To explain the hairiness of this a little better in our case, the actual "migration" procedure looks like this:

ok so that was the exact phrase that when searched didn't show up, it works fine here

Notes on setting up Vagrant with libvirt support

I think we were using strings that were too long when checking this out on our production install.

I can't close this task to spite myself.

(apologies if this recently changed, I'm a few weeks behind master)

Yeah, we have some packages which are generated by another application, and some which are generated by users, I wanted to lock the field only when the package was generated by the other application, this is a simplified version of the actual extension in place.

Can I get clarification on philosophical opposition to this? Is it leaking abstraction of the "icon" interface to the end user?