After further careful thought, I suppose introducing a "Protect Build" action might be better than rate-limiting build kills. Users protecting a build would increment a "Shield Level" counter, and users trying to kill it would decrement the "Shield Level". Once the level dropped below 0, the build would be terminated. So you could band together with 3 team mates to give all your builds a Shield Level of 4, and require a team of 5 or more attackers to steal your resources. I think this would immediately lead to a fair market for build resources.

Alternatively, we can provide a "kill enemy builds" API and a "your build got killed" webhook and let everyone sort it out for themselves. We could put an action rate limit on build kills so people would be incentivized to band together into coalitions since they wouldn't individually have enough power to kill everyone else's builds or defend their own builds.

(And the build-level buttons would only affect plans you could individually affect -- the build-level "Abort" just means "click every step-level abort I have permission to click".)

why is she running so many builds, that's ridiculous, I should stop these so that my builds have a chance to use the build servers

The original driver here was a very complex one (requiring instance-level, non-registration OAuth links to services) but that never went through.

Resolved via email.

If you definitely want to delete the user (usually, it's better to just disable users), can you shoot us an email at support@phacility.com with your instance name and the user you want deleted?

Yeah, I have the same guess as @chad on this.

This does not reproduce for me with Chrome 46 on Windows 7.

I also can't reproduce this with a similar setup (OSX / Macbook / Chrome 46).

See T7740 / https://code.google.com/p/chromium/issues/detail?id=473657 for a previous adventure with scrolling Chrome anchors.

Ah

• Mailing list users can currently be made into administrators. We should probably prevent this, because it seems silly. (Making a daemon an administrator is still silly, but doesn't seem completely unreasonable.)
  • Regardless, users can be marked as mailing lists and also as administrators in the database.
  • bin/auth recover will let you recover users who can not establish web login sessions as long as they are administrators, but should not.
  • When you recover such a user, a misleading error message is shown (session invalid). Instead, recovery should fail explicitly and/or the session error message should point at the root cause more directly.

I think this is generally reasonable, but this is the tricky part:

Oh, you need application/json or other weird stuff.

Does adding variables with ?var=value to the URL definitely not work?

T9352 has an early approach for parameterizing builds via Herald which might let you collapse some of those rules.

If you've forked, you can also just move stuff into src/ourcustomstuff/ and use arc liberate, arc unit, etc., at top level. This may have an overall lower maintenance cost than splitting a library out given that you're already bearing the cost of maintaining a fork. Only src/extensions/ has magic behavior.

We always load everything in src/extensions/ when starting up, which is why this is loading.

Calendar's still a prototype and we have a few unfinished pieces like this, but we can keep this around as a reminder until we finish it up.

I don't think that would impact the outcome here. ssh-auth would still fail: I believe the problem is that php is in /usr/local/bin (or maybe /usr/games), so ssh-auth can't execute without that in path.

This endpoint is very old and has a lot of problems, including not being cluster-aware. In the Phacility cluster, the web host and repository hosts are separated. repository.create can not create cluster-aware repositories.

For what it's worth, I don't use phabricator-ssh-hook.sh at all, I find it to be much simpler. Instead o use the following SSH configuration (which also allows me to run both administrative and VCS SSH over pirt 22):

I deployed rP4c1463eb to this server and the reproduction steps above now work correctly, so I think D14311 fixed things. Let us know if I missed anything.

Thanks, that's very helpful.

Alright. In the short term, you can bin/worker cancel --id <id> any tasks with a bunch of failures to stop that specific task from retrying. Presumably a handful of problem tasks are causing the majority/entirety of the issue.

Have you used bin/remove destroy to delete any diffs or revisions?

The Mercurial upstream fixed this but we need to retain the (1 or 2) or (3 or 4) code for backward compatibility anyway, so I don't plan to remove it until we run into a real problem it causes other than "it is icky".

I don't remember what the original context was here, but T9319 is likely a reasonable proxy for it.

This does not appear to describe a reproducible issue. See:

See also T4245.

Subversion does not have top-level branches or tags; these features are purely conventional.

• rCALLSIGN autocompletes.
  • r substring, where "substring" is a substring of the repository name, jumps to matching results.

Sorry, this fell through the cracks -- feel free to make noise about anything policy-related like this if I don't pick it up in a couple of days.

Maybe rename the edit page "advanced" or something, and let anyone with "can view" see it?

See also T9192.

I think this is a very low-impact change, but not an unreasonable one (the data is already available on the object, I think, and we do already show "Inactive", which is a somewhat similar state). This would make the list view marginally more useful in a tiny number of cases.

Oh, sorry, I'm just moving stuff around on some boards so I can feel accomplished.

Do we actually have a reproduction case for this? I'm not sure where I'm supposed to click getLinterName to reproduce this.

It looks like it still has trouble properly rooting the files. Maybe a good way forward here is to always use their absolute path in the repo instead of trying to tie them to some subdir?

I'd like to see more users encounter difficulty here before pursuing any of this.

We explicitly do not cover setting up init scripts. See T4181.

Okay. This report doesn't appear to describe a reproducible problem. See:

Ugh, it's too hacky. I'm just going to put a manual redirect in place for now instead.

I'm just going to put a redirect map in the book for now. This isn't a great long-term solution but I want to move forward on D13941 in some form.

APC and APCu are different. Basically:

But you say the message was preferable to the consequences of the possible fix without APC?