As discussed in IRC, I think providing more than 1:1 relationship at this stage complicates things (like auto-discovery) for some very theoretical use cases. The changes made in the diffs attached to this task actually do the heavy lifting of allowing Celerity to serve from multiple resource maps. Changing this in the future to pull from other locations (such as a resources/maps folder) is reasonably trivial to do if there's ever a concrete use case where we would benefit from a 1:* mapping.

The only thing with decoupling them completely is discovery; how does Celerity discover all of the relevant maps to load? Do we use the file finding class to search for all files called __celerity_resource_map__.php across all libphutil libraries that are loaded? That seems reasonably expensive.

We use submodules a lot, so that's probably like 90% of the issues.

I don't think that will be an issue in practise as I can't see where you would have "version-1.0" folders. It's much more likely that you'll have a "version-1.0" snapshot on the "releases" folder, and you will promote the "stable" snapshot up to different versions.

@epriestley I'm looking to finalize this into a Beta state alongside Phragment by the end of this week. Are there any remaining essential items you'd need in Harbormaster before it's ready to be used by everyone (albeit under a Beta flag)?

• if a user manually kicks off a build, then they're considered to the user when evaluating policies around drydock
• if a global herald rule kicks off a build, then omnipotent is when evaluating drydock policies
• if a personal herald rule kicks off a build (which we don't allow yet), then the owner of the herald rule is the user when evaluating policies

This isn't much of an issue any more. For me, I simply defined a search called "Important Repositories" with the callsigns I'm interested in. It might be nice to allow administrators to make their searches public (so for example I could set "Important Repositories" as the default for anyone opening Diffusion), but it's not critical at all. I'm generally of the opinion that having the dashboard public and showing recent activity will be of much more use than this task.

Correct.

Hmm, I thought this might have been possible with HTML5 Application Cache, configuring it to cache pages and use them if offline, but it looks like there's no way to configure it to use the online version when you're online, without explicitly clearing the cache from the server-side.