ignore this - test

The infrastructure changes should now be complete, and we're clear to start experimenting with the UI. Progress so far:

(This is paused since we're waiting on feedback -- if you give it a shot, let us know how things go.)

I'm going to sort out the infrastructure issues first, then we can see where the UI goes. Specifically:

Does this being added to 'Prioritized' mean Phacility are working on it, so
there's really no point in me plodding along trying to do it? :-)

Hi all, glad to see this issue is being looked at. Per my task in T10641, simply having "all documents" search show the same style of content as is seen in Maniphest search would speed up our day to day, as most people on our team use all documents search (unintentionally, as it is the default), even though all they really care about is Maniphest, and so their experience isn't great here (their impression is "Phabricator search isn't good" which I think is related not to functionality but discoverability and smarter default configurations).

• Once D15499 lands, this is available as a prototype.

The technically-functional-prototype code is live on this install, now:

Quick update:

One issue which we'll hit eventually is that git-lfs doesn't currently support pushing to remotes by URL, but we push to staging areas by URL:

No way for the upload API to say "no thanks, I already have that file"?

Quick progress update:

Before I forget:

Adjacent work:

Various notes from prototyping:

Upstream builds have been in production for some time. There's always more work to be done, but I don't think there's anything actionable left here that isn't covered elswhere.

This is now substantially complete.

I believe we generally have an acceptable way forward here, at least in broad strokes, now so I'm going to close this out since I think it has served its purpose, but feel free to file a followup if things stall or you run into trouble.

In T8434#151667, @Krenair wrote:

I think one of the issues was people making a public task, and then deciding they should change it to security, but not having the permissions to do so?

We ran into a case where archived packages were trigger builds, which didn't feel right and was causing problkems. I'm not sure what the default behavior loadAffectedPackages should be or what would be most consistent with how archiving is handled elsewhere.

I think one of the issues was people making a public task, and then deciding they should change it to security, but not having the permissions to do so?

Awesome, glad to hear things sound promising. Thanks for the update!

@epriestley: We haven't pushed this to production but my initial impression from configuring forms on https://phab-01.wmflabs.org is that this should work pretty well. The only thing I haven't figured out is a way to easily transition a task between private & security sensitive and public. It seems that will require someone with adequate permissions to manually edit the task policies, which isn't the end of the world. We could possibly continue to use herald rules to make the transition easier, though I am more keen on the idea of totally killing off both the herald rules and the custom event listeners.

Custom fields (and paths, too) can now be read with owners.search and written with owners.edit. There's a description of a more complex edit (against paths) here, but the same general workflow applies to examining and updating custom fields:

In T8434#147963, @epriestley wrote:

I ultimately expanded the scope here into a lot of adjacent work in T9132, but a rough version of "better templating" is now available in HEAD and deployed and configured on this server. There's documentation here:

https://secure.phabricator.com/book/phabricator/article/forms/

This is still a bit rough in places and probably has some bugs, but I think the big picture stuff is working reasonably well and mostly usable.

I ultimately expanded the scope here into a lot of adjacent work in T9132, but a rough version of "better templating" is now available in HEAD and deployed and configured on this server. There's documentation here:

At HEAD, you can now edit this field via the owners.edit Conduit API method.

In T2543#144462, @jsturgeon wrote:

Any way to bump the priority of this up?

Any way to bump the priority of this up?

@epriestley I'll keep an eye on blueprints and the merge configurability. Thank you. Phabricator is awesome/and getting awesomer.

Are you planning a fully specifiable merge command so we can run anything we want for merging?

All the policy, merge strategy, etc., stuff is hard-coded to the easiest set of reasonable defaults. Some of these defaults may not be suitable for many installs (e.g., always rebase, always merge to master, require edit capability for imported repositories in order to perform merges). I expect to expand these shortly, I just don't want to focus on making things more flexible until they actually work.

This is already prioritized, yes. See the weekly dev log for my plans through the end of the yar.

Is this likely to be completed this year? We have some teams expressing interest in this feature and I might be able to convince management to get onboard with paid prioritization (although this ticket is also prioritorized right?)

I think the discussion is in T8090.

I can't remember which ticket, but I remember a similar discussion regarding arc patch (whether arc patch should patch onto HEAD or pull from the staging area).

Yes, that's what this refers to:

Because this works from the staging repository, it will be possible to trick it right? I mean, I could do this to sneakily commit virus.exe to the repository:

I'm going to close this out as I think we're generally in good shape here and we're now hosting builds and doing server-side lands in the upstream, and don't anticipate much more Drydock-specific work in this iteration.

This is in reasonably functional shape for ambitious users. There's some documentation now:

The action is always available right now because it makes testing (particularly, testing things like "does it do the right thing when the revision is already landed") easier, but I'm going to require "Accepted" for v0 of this, which will indirectly disable it for landed ("Closed") revisions. We'll probably relax that later but it seems like the right place to start from, at least.

I think we should disable the "Land Revision" action item if the revision has already been landed.