This should be fixed in Week 17. See T8952 / D15773. Let us know if you're still seeing issues after upgrading, or can reproduce the problem on this install.

we'll get to it when we feel like it (ok not a totally fair paraphrase, but it's one way to read it)

Perhaps helpful for context is T6027, which was open for longer than this (about 18 months).

What isn't helpful about it? I believe it has a complete answer to your question, and a great deal of detail explaining why that's the answer. How could it be more helpful? Did I misunderstand what you're asking?

I suspect this isn't a bug -- diffs have repository associations, and you must be able to see a repository to see associated diffs. You must be able to see the active diff to see a revision. So andy caused the active diff to belong to a repository that nuno can not see, which prevents nuno from seeing the revision.

I'm going to merge this into T10748, which is now more clearly the way forward.

See Planning for information on timelines and progress.

I'm going to merge this into T10748, since that's now clearly the way forward.

I'm going to merge this into T10748 because that's clearly the pathway forward now. You can view the new UI at /diffusion/X/manage/, although it mostly doesn't work yet and there are no links to it in the UI.

T10751 and T4292 are reaching a steadier state now and have some indirect/soft dependencies on this (for example, the new panel for monitoring the cluster status of a particular repository is part of this new UI) so I expect to drive this forward at least somewhat in the next few days. I'm not sure how ambitious I'll feel about meddling with the URI code before the release cut, but there's a good chunk of basic work remaining before that becomes an issue.

See also Contributing Bug Reports:

The instructions are correct as written, and are aimed at being as simple as possible for users who may not be familiar with PHP. We can not possibly include instructions for every imaginable installer, see also T4200.

In particular, the install instructions tell you to:

How did you install PHP, exactly?

Yeah, measuring latency and using it as a signal is tricky. If there's a long disruption and Oregon measures faster than N. California for "a while", we probably legitimately want to use it. If N. California completely goes down, we almost certainly want to keep things alive and send writes to Mars, even if Mars is at a huge network distance, since "slow write" is probably almost always better than "complete failure" (although maybe Mars bandwith is so much more expensive that we don't want to fail over to it, or the size of the link is small enough that it simply can't accommodate the failover traffic).

Ah, link speed vs latency is interesting.

Is "use measured latency" probably always the correct rule in your (hypothetical) cluster setup? Or do you have any cases offhand where it isn't the desired result, and you really want to send traffic to a more distant node on the network?

I don't currently expect anyone to be deploying multi-region clusters in the first iteration of real clustering, so this isn't high on my list of things to fix in this round.

See also T10884 for related work: ranking similar nodes more intelligently.

See also T10883 for related work: making some nodes read-only.

Thanks -- T10778 had instructions which I was more successful with. This should be fixed in HEAD.

Oh, thanks. I can reproduce this variant of things. I thought I remembered seeing this...

Do you have a stack trace in your webserver error log? (Often /var/log/apache2/error.log or similar.) I can't immediately reproduce this myself, but that might help narrow down the cause.

The GIF data is set to repeat the animation only once (see circled control in footer):

• (T9516) Use the same copy/paste line number stuff that Paste, Diffusion, etc use.
  • (T10179) Make formatting smarter. For example, the "Run CircleCI Build" plan produces logs that we know to be HTTP headers (which we could format as a table) and (almost always) a JSON blob (which we could format as human-readable JSON).
  • (T8656) Make one of the smart formatters "ANSI".
  • I'd like to style this like other stuff (Paste, Diffusion) and let users pick dark themes globally with T5701 if they prefer.
  • Logic for loading the data is clunky, and fetches much more data than it needs.
  • Clicking pager links affects all build logs on the page, this should probably be JS-ish at some point.
  • Pager logic often feels clunky to me. For example, if a log is exactly 21 lines long, we still show pager controls. If a log is 27 lines long, we should probably show the whole thing. "Show more" would be more consistent with how other pagers work, etc.
  • (T6139) Not sure if this is really the right way to frame it, but we often have information about how useful a build log is and can do a better job of organizing them (e.g., successful build logs are usually uninteresting and could be folded by default).

@hach-que, that plan sounds good to me.

Not directly to your point, but you can remove or shorten the [Differential] token by adjusting metamta.differential.subject-prefix, if you didn't stumble across that already.

I'm still not really thrilled with where the documentation situation on repositories is, but it's getting a little more manageable.

Here are a few ideas that might shed some light on what's happening:

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

arc diff is supported, but most of these reproduction instructions don't make much sense to me in the context of arc diff -- for example, arc diff does not apply patches.

Specifically, any effort to reproduce this in the upstream will meet this grizzly fate on the arc test step:

Yeah, arc test is not part of the upstream.

This is a Bitnami issue, and you should report it to them. See Contributing Bug Reports:

Maybe also reasonable would be something like this:

One thing we could do to improve this is version daemons in /daemon/, so your "go to sleep" routine could be more like:

You can use bin/phd reload -- instead of restart -- to instruct daemons to exit and restart only after completing their current tasks, with no time limit on task completion. The semantics on this are necessarily a little fuzzy, but basically:

This document is already large and complex and the source of many configuration mistakes. I worry including basic information like this could cause more harm than good, by making the document even larger and making it easy to miss something important.

That is, we normally navigate complex configuration by verifying every step and just telling you what's wrong and how to fix it (e.g., moving all the MySQL, etc., configuration from documentation to automatic setup issues was a huge step forward), but there's basically no test we can perform on most of this chain.

In general, this configuration is a huge horrible mess but I'm having a hard time coming up with ways to really fix it that don't just tell you to run everything as root.

Oh, I think I have a handle on the first issue -- you can ignore my questions about that.

It turned out that the git-user (aka vcs-user) created files as phd:phd

This also reproduced locally for me (OS X Yosemite, openssh-6.7p1), and chmod on the parent directory alone was reliably sufficient to prevent SSH from working. The instructions already suggest a root-owned location, but D15794 notes this requirement explicitly.

I can confirm T9560 locally, at least, so that might be the problem or part of it -- maybe start there? If you can provide details we're happy to fix this properly.

Yes, you should NOT set AuthorizedKeysCommandUser root, this is needlessly dangerous and gives the script substantially more permission than it needs.

I also caught this vaguely related downstream report of markup list styles not rendering properly in mock descriptions:

After we receive a push, try very very very very hard to release the lock if we're the thread holding it, even if we lost the global lock