The objectives UI wasn't solving any specific problem or really motivated by any particular request, I largely just wanted to try it out and see if it made it a little easier to navigate diffs in general. I think at least some of the feedback in the vein of T8250 is roughly "it's hard to see the big picture when changes have a lot of comments", and it seemed worth trying to see if we could make the big picture a little more clear without splitting the UI apart completely. Some (most?) IDEs have similar features, where either things like functions/classes, or lint warnings, or compile errors, are marked in the scrollbar or a small view of the file is shown:

If you haven't checked anything and are the author (i.e., today, button is visible and says "0 / 2"), clicking it takes you to the first inline. That's at least a plausibly useful behavior?

"3 Unsubmitted" is the three synthetic lint about "TODO"s in the code (see T12806).

Yes. (That is, I'm adverse to upstreaming this.)

We haven't received the information we need to move forward, so I'm going to close this. Feel free to follow up here or open a new task if you're able to provide detailed reproduction instructions we can use to reproduce the issue locally.

"Wait for T12681, then pay us a lot of money." See also T12778.

I think "search across multiple repos because we have 2,000 extensions" or whatever is a great use case, that just didn't seem to be the motivation of any of the requests above -- I think it wouldn't make sense to put cross-repo search on the main page of a particular repo, or particularly on subdirectory browse views.

Maybe this is a better screenshot:

Slightly less important is that the width in the Browse File page is limited

This is now deployed here, to secure.

When I view a repository, it would be incredibly helpful if the files I most recently touched were at the top of the UI.

You can use, for example, -C3 with git grep to show 3 lines of Context around each match.

What do you use file content search from the web UI for? (That is, in what situations is web UI search better than git grep?)

(I think that's also filed in T10767.)

In T12804#226290, @sascha-egerer wrote:

T8442 would help a lot for those "I have to many repositories"

GitHub, which has an omnibox

I queried the production backup log to find the maximum size of any active instance's backups to contextualize decisions around backup and storage management in D18094.

Comments are fine.

Conveniently, bin/restore already exists and does much of the above, although it doesn't have a --download flag yet and its current behavior is to abort if data already exists.

Actually, from the logs above I didn't even do it manually and just made it up for no reason.

Thinking about this a little more, there's really no reason to do any of the rebinding stuff until after we move the data. I did that earlier when moving manually, largely for convenience -- but we don't need to sequence things like that when automating, particularly if we don't need bin/storage to work on the new database.

I think we have a generally tricky situation on the database stuff here. The general algorithm this process is using so far is:

This is because of the synthetic comment from Lint near line 108 of DiffusionHistoryController.php, not because of the comment in the screenshot.

(That said, GitHub does show an accurate count so who knows. Maybe the page is slow because they aren't doing anything stream-oriented. In this case, a directory with 3M files probably just crashes.)

I also suspect that GitHub compromises here for performance. If you look at a very large directory on GitHub, it shows only the first 1,000 files fairly slowly (page takes 1-2 seconds for me) with no pager, and a warning that the directory is too large:

The reason this isn't trivial is that we ask git, hg, or svn for a list of files, for example with git ls-tree.

yes I believe you have been coaxed into a clever trap -- and your predicament is of your own making!!!

(Poems doesn't have an example of the first kind of directory, and I don't know of any offhand, but you could build one locally in a couple minutes I think.)

Offhand, I don't know if the kernel has directories with a lot of files in it or not -- like, Phabricator itself probably has only 1-2 directories with more than 100 files (resources/sql/autopatches/) and might have none with 100+ files and directories, so you could implement this wrong (pick the first 100 paths, then sort them by "directoryness") without there being any counterexamples in Phabricator. It's possible the kernel is the same.

Or, specifically, a list of files like this:

(That is, more than 100 non-directory files.)

I don't care too much.

We could also let you collapse/expand columns like your mock in T6642. None of this hide/show/filter/collapse/expand stuff is hard -- T11036 and T4900/T10336 are the only really involved JS changes in queue for workboards, I think. It's largely just not clear to me which subset of the proposed tools is most useful, and it feel like major overkill to implement all of them.

But it's mostly moot until T11036 I think. T5024 is vaguely related ("filter to just one column"). T6642 might be related ("save collections of columns") but my recollection is that task was a bit muddy? I haven't re-read it recently.

That's very easy, just a question of whether we want to add the buttons/menu items for it.

One minor fix would maybe be to put "Create Subproject" first on the "Subprojects" page. This is inconsistent anyway -- the tab is called "Subprojects" and the header is "Subprojects and Milestones", but the order in the action column, the curtain panels, and the main panel is "Milestone, Subproject". I think this stuff blame to me in D15152, but "Subproject, Milestone" is probably a better order both for consistency and to gently nudge users toward the more general / less specialized unit of project division.

I don't think this should be a language problem or that "Milestone" should communicate "flexible target" -- physical milestones are big, immovable, evenly-spaced chunks of stone with a single increasing integer chiseled into them. They're a really direct metaphor for the behavior of milestones as implemented in the product. But feel free to send me a diff to swap it to "Iteration" if you think that's clearer, I'm not married to "Milestone".

If anything, a hypothetical "Progress" tab should show ALL subprojects and only a SUBSET of milestones: just the last, current, next, and maybe +2 / +3 milestones. If your work is really linear and time ordered the progress of the milestone from five iterations ago isn't relevant most of the time.

That is, milestones largely exist to support future features that depend on a linear ordering, like "push all open tasks to next milestone", automatic creation of the next milestone from typeaheads, automatically scheduling milestones sequentially for charting/reporting, etc. If we let you reorder them most of that stuff sort of goes out the window (or, at least, gets much more complicated). And if these features aren't actually important, I think we could possibly just remove milestones from the product.

There's no technical reason we can't let you reorder milestones, but adding features that let you bind milestones to time ranges may be much more difficult if we let you reorder them.

I think that's conceptually reasonable, but I can't come up with any reason offhand that it should be restricted to milestones instead of showing both milestones and subprojects.

Yeah, I'm pretty sure there's no difference.

What behavior do milestones have that subprojects lack (or vice versa) which is relevant for progress tracking?

Why would you want to set those up as milestones instead of subprojects?

(None of this impacts anything outside the ops realm in any way, except that some of the admin/ops-flavored UIs are changing a little.)

There will be a final written exam on June 19th.

Er, that was rCORE085cd7e4 but I typed D instead of T.

I inched us forward on getting EC2 and Almanac to agree with one another, but need T12414 to make much more headway:

I can't reproduce this. Here's what I tried:

Here's a version with =cmd|'/C evil.exe'!A0 if that produces different results:

Some of the syntax has changed slightly from the above, but I think the overall plan remains basically correct.

phage remote status --pools db,repo and such work now, using Conduit credentials from the bastion to query admin. We can swap that stuff later if we want to switch to EC2.

Come up with a plan for where phage --pool repo is going to get the host list from.

Good to hear, thanks!

If anyone actually has bona fide Excel.exe installed, you could try opening this file to double check that we're not currently vulnerable:

I think I disagree with this but I want to be sure about what you're saying.

If we stop generating internal IDs from instance names, I think we should pick a generation scheme such that they can not ever collide -- backups/ErrantAnalyticalGiraffe/ on disk should never exist and be a different instance than ErrantAnalyticalGiraffe.phacility.com in the web (technically these namespaces are different today because you can not use uppercase letters in an instance name, but that feels very flimsy as a dividing line).

Another adjacent piece of work here is automating provisioning (e.g., through autoscale groups or bin/provision) but I think we should mostly leave that for the future too since we're theoretically bringing up only one new host (or maybe two, natXXX + repoXXX). Many of the other changes here give us tools toward that anyway, and it would probably be better to pursue that as part of a future change that involves launching a larger number of new hosts (e.g., chassis swap on the whole tier).

I plan to take these steps specifically:

@amckinley, I'd like to try to do this as part of T12798. Here's my rough understanding of what we need to do:

To summarize where we've ended up:

The general shape of the change is reasonable. However: