I've taken a pass at this in the design on Phriction v3, and it's top level comments only. The comment pane by default is hidden, but expandable. You can see comments on previous versions, and pull them up separately. I think this is a reasonable place to start over inline commenting and trying to recreate Dropbox/Quip/Google Docs, etc.

I cannot reproduce this as stated. Here's what I did.

Also, your steps to reproduce contradict your description.

Can you reliably reproduce this each time? Can you post your version information as required?

We didn't have cheering shirts this year.

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:

Winter is coming.

The sno-man is optional.

it's just likely very complex when we have to save an entire object state ... instead of approximately a single blob of text

Understood. For me personally, the single blob text would be more than sufficient. I don't mind repopulating everything else (assignment, subscribers, tags, customs, etc.) as those usually require much less thought and drafting.

In my setup, we have cross-repository tests, so there's maybe 4 jobs that need would run would each run when one of many repos change; So it's similar, except that I filter on "Repository Project Contains".

The way I've configured it in the past is to have the build trigger an HTTP call to a parameterized jenkins job (passing the various vars required to update w/ harbormaster.sendmessage). In the past we've needed each team to have / manage a different jenkins job, and so we created a new build plan for each w/ a different HTTP endpoint to call.

Why does each repository require its own herald rules/hm builds, if those are not customized by the team?

Thinking a bit more about the herald / harbormaster approach, I think what might help that workflow, for me at least, is conduit API access to create herald rules and harbormaster build plans.

Can we fix this problem (or set of problems) instead? The workflow you describe is not something we're interested in spending resources supporting since it is much more limited than the Herald + Harbormaster flow in the general case.

Ok, I'll mock it out.

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

Where is that checkbox?

(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:

Can I select which page I pull my hierarchy from? I think that works for cases where you want the navigation to be persistent among the children, to just always pull from parent hierarchy.

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:

So just to understand your point, instead of having pre-selectable layouts, we ship just 1 level by default and anything else is custom?

My intent was to basically port over a customizeable nav list like we already use in AphrontNav everywhere, label, item, spacer, and have that basically editable and re-usable. I want to take a pass at something similar for /home/ so we're looking at all the use cases before building anything.

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

Apologies, I should have added more detail to the original task! I am actually trying to use just the staging push to trigger remote tests, and not require each project to setup and maintain herald rules + harbormaster build plans that call out to HTTP endpoints w/ parameters.

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.)

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

How would this work in CI? We use jenkins to test differentials. Herald starts a jenkins-job when a differential connected to a spesific repository is created or edited. Heralds sends the repository URL and commit id of current HEAD in differential to jenkins, and this then runs tests on HEAD of differential using

arc patch --nobranch --no-ansi --diff $DIFF_ID --nocommit

Added in commenting.

Closing as invalid since we have no idea what this request is even for. IMAP is a mail protocol, and I'm not sure what you're asking us to do with it.

See Contributing Feature Requests and Describing Root Problems for what information we require in a feature request.

https://chrome.google.com/webstore/detail/lazarus-form-recovery/loljledaigphbcpfhfmgopdkppkifgno

Maybe not exactly related but we'd love this feature for harbormaster build status page.

FWIW this exact set of reproduction steps no longer works. However, an Owners package set to generate an audit, but without any members, will be unclosable as well.