(Just so no one thinks too highly of me, I'll underscore that I very briefly peaked at #11. I think I had slid to about #35,000 by the end of the lightning round and "-∞ dumpster garbage rank" by the end of the competition.)

Sadly, I didn't win ICFP with PHP this year. I got up to #11 (just 33,600 points from the top slot!) but had to go to a meeting in the morning:

When you click the pencil icon next to the "Hierarchy" item, you get to a page like this one:

(I'm hoping there's no real use case for "show some other arbitrary page's navigation", although who knows.)

I'm hoping to get away with two options, e.g. a checkbox like this:

I found that the overhead of managing herald + harbormaster was much higher than our previous setup and was causing friction getting folks to adopt phabricator for new projects

Yeah -- the specific change I'd expect is basically that this:

These use the prose algorithm now, and I don't plan to try to implement syntax highlighting for prose diffs.

I think both are about 95% equivalent, my version ("a Hierarchy is a single menu item") is just easier for me to do from an engineering viewpoint and the other version I'd have to think about for a while before I could even guess how much work it is. I think the simpler-to-implement version is a bit more flexible/powerful too, although maybe not quite as intuitive at first glance.

The shortest path on the nav is probably something slightly more directly porting Profile Menu editing:

We will almost certainly never support diffs coming from multiple different repository sources. They can't be built, can't be updated, can't be patched, can't be meaningfully interdiffed, local commits are meaningless, can't be atomically landed, and they basically don't make sense in general.

Can you walk me through your workflow in more detail? The expectation is:

This is nice in theory, but I suspect it may be very complex to implement in practice.

(I've destroyed the token compromised earlier in this thread.)

Try differential.querydiffs.

How would we distinguish between source/android/browse/carafe/ being "browse branch carafe of repository android" vs "browse the home page of repository carafe located at path android/browse/" in such a scheme?

This document may also be helpful in scripting Phabricator commands:

The Aug 19 2015 reply from James Day in https://bugs.mysql.com/bug.php?id=66546 gives me some hope that MySQL may adjust behavior here. Although that comment is now almost a year old, it responds to a comment from about two and a half years prior, so this may actually be fairly new in MySQL timescales.

I think this is the corresponding MySQL bug:

We can limit the number of instances, but I think the big question we want to answer is how many free instnaces convert to paying instances over some long period of time.

I think this is reasonable to pursue, but I'd like to put the capability at the ApplicationSearch level rather than making it specific to one field in Feed -- basically, provide not(user) and not-viewer() or typeahead functions (or similar functions with better names).

Cool. We can build this later for "free tier trial" if we do that, since we would definitely make different decisions based on the data then (0% conversion = don't do it, 100% conversion = ship it immediately, somewhere in the middle = run the numbers or whatever).

Oh, I can skip it if you aren't too concerned about it, it just came up and I didn't want to forget about it. I think it's like 10 minutes of work, but I'm perfectly happy to not do that work too. I don't think having this data would change any decisions I'd make, at least, even if the data showed extreme results:

I think this should be fixed in HEAD of master now. It should promote to stable pretty shortly, probably. Let us know if you're still seeing issues after updating, and thanks for the report!

I'd theoretically be open to doing that kind of thing, but I worry it would waste a lot of our time in arguing over whether or not something is really a good bug report or not. We already see a lot of this with our security bounty program and the definition of a valid report there is very narrow.

I think we already add this flag in most cases (via ArcanistGitAPI->getDiffBaseOptions()), but the specific check in arc land doesn't go through that code (since it doesn't really care about the diff, just if the are any changes at all).

Cool -- I don't think we can really detect this because we don't have an opportunity to run any code to check for it. We could possibly have the web UI run a setup check, but I think we get about 1 of these a year and it's reasonably likely that users try to run bin/* before hitting the web UI anyway. If you have any ideas about how we could have caught/prevented this, let us know.

They should be symlinks. As git represents both symlinks and the executable flag, it should be unnecessary to chmod them.

ICFP2016 starts in about 6 hours:

(Possibly it might be easier to select the correct audience in Phabricator since you can use projects or other rules, but all of the use cases here and elsewhere just want to hit everyone, I think.)

Yeah, basically like the Facebook Rooster system except making it act as "pinned notifications" instead of "pinned dashboard panels". We could do either, reasonably, although it's slightly messier to do a real-time notification of "a new panel appeared on all dashboards, go look". But I'm basically not sure why this is better than email in any case where the users are employees.

I think a global banner (or some equally omnipresent, persistent element) is reasonable for "this system is going down in a couple of minutes". But if that's the only really good use case we have for it, though, I wonder if we shouldn't just build a "shutdown in X minutes" feature that automatically does this, counts down, stops new batch jobs from starting, maybe pauses builds, puts the system into read-only when the countdown finishes, etc. -- a dedicated "graceful shutdown" feature instead of just a broadcast feature. I don't think any of these things are really problems today, but I could imagine more of a "shutdown process" being useful in the future.

Yeah, agreed. I added a little discussion to T8145.

@bjshively, for this use case:

• T11427 is similar.
• T10855 discusses a similar and possibly overlapping use case (mirroring system status into Phabricator), but I believe that use case isn't after global/on-all-pages notifications.

T8145 is also related, and maybe a little closer to intent here. I can retarget that.

T11428 puts the corporate communication wheels in motion to make this change.

Update past rPa5b26104 (Jul 9).

Closing this since we haven't seen a response for about a week, this report didn't follow the instructions by omitting version information, and it's very likely that this is resolved by updating.

Yeah, T7447 is probably the best source of discussion about this.

D16367 make the order consistent (instead of reversed) in the task list view and on workboard cards.

I think this is a perfectly reasonable capability to want in the general case, I just want to make sure that this isn't a big fancy solution to a problem that could also be solved by checking a checkbox or making a one-line change to the build or whatever. Definitely possible that most Jenkins users are just doing very basic stuff with it, though.

I'm not super familiar with Jenkins -- what makes this job require parameters in the body? Other users seem to be using Jenkins successfully without requiring this capability on the Phabricator side, as far as I know.

Ah, that one's easier.

@eadler, does your use case need a fancy content type like application/json, or just plain old www-url-normal-web-form-encoded?

I don't think this is a sort stability issue: we're preserving the order which the user who entered the tags originally used (in this particular UI it looks like we actually use reverse order, which I'd consider a bug, but other UIs like the "Tags" in the rightmost column and when editing the tags via "Edit Task" we use the original order).

Just to be completely sure I understand this:

You can use --verbatim to cause this update.

Just to clarify, workboard columns with a limit should currently show text like this in the header:

If you can identify why sudo was broken and what you did to fix it, we can probably add a setup warning to test for this problem. However, since we haven't seen other users with broken sudo and we couldn't help users resolve the issue with available information even if we did detect it, I don't think pursuing a check in the upstream is worthwhile.

(You can't write "Run Build Plans: ..." personal rules, but you can write them in object rules, which isn't too much different.)

It's also probably bad/inconsistent that you can run builds via Herald which you could not run via the web UI.

I have mixed feelings about relaxing this. I think there are basically two parts to this: