This report is about a year old, things have changed a lot, and I haven't seen other reports and can't immediately reproduce it.

This has changed a bunch and I haven't experienced any difficulty with it in the last year or so.

Well, no level other than 0.

Yeah -- we can pursue that stuff, but I'm strongly suspicious that user complaints about mail volume aren't meaningfully correlated to actual mail volume and that there is no level we can drive it down to which will meaningfully reduce user frustration.

And I generally agree about dependencies and externals getting ignored for now, but I'd like to assume we'll eventually support both and plan around that.

On these things:

@chad, do you have any particular objections to disabling all mail (other than welcome / password reset mail, which we obviously need to send) by default-default after we give administrators tools to selectively adjust the defaults in T5791 / T4103? It feels a little extreme to me, but I think we're going to be dealing with this forever if we don't do it.

Put another way, the one case of this which I've conclusively pinned on a root cause was "user is wildly sensitive about email and also would rather complain about it over and over again than spend much less energy fixing the problem", and the fix was "look up volume statistics, roll eyes out of sockets".

Product reasons normally, although technical reasons if metamta.one-mail-per-recipient is enabled (we can't batch mail which must be delivered to multiple distinct recipients).

For example, suppose A is on B, which is on master.

As a reviewer, I expect the code that lands to be the code from the revision web page

Yeah, that's exactly what I'm imagining (I mean, maybe not exactly that command, but that workflow). Then I can sign your packages as Phacility and users can see that they're trusting your claim about the package, but that Phacility also supports your claims about who you are and your claims about the package.

Thing seem quiet now.

I think we could pick any available UTF8 locale here safely, as they should only differ in collation rules (I think?) and I don't think we ever rely on VCS commands to sort text. I'd also favor a setup warning if only a small number of user are affected and it's easy to install/generate locales, though.

How do you detect that a locale is missing? Parse locale -a?

The broad issue with making this process have fewer side effects is that it potentially makes it much harder for less experienced users to understand what's happening and what state they're in. My experience at Facebook was that a majority of engineers learned as little about Git as they could in order to do their jobs, and I would not have expected many of them to understand concepts like a "detached HEAD". I'd guess less than 20% knew about or were comfortable with git reflog.

I think we can just take the tree hash (git show -s --format=%T) and sign that [1].

See also T6502. Our handling of permissions here has changed a couple of times and this should never be greyed out, I think.

Modernizing -- the timeline needs setQuoteTargetID() and setQuoteRef() to activate "Quote". This should be more automatic than it is, but the comment boxes are custom per app right now. If you want to go manually add the calls now that'll work, or we can wait until this gets a general modernization pass and should pick it up for free.

Some SearchEngines don't provide any fields.

Would this solve your problem?

Yeah, I generally agree with that direction. I'm not really even sure if we need anything, or could maybe get away with a binary thing (like "good", which makes the answer gold and promotes it to the top of the page) since a lot of the "such wow" stuff can probably be covered with tokens.

I think everything actually implements PhabricatorPolicyInterface now, and the rest of this is covered by T8633 / T8634 (when modernized, project filtering happens for free).

Particularly, I would expect the total cost of ignoring master to be that git branch has one extra line. At least for me, git branch is useless as a routine command anyway:

I'd like to see reports from at least a few other users before pursuing this. I believe this workflow is highly unorthodox, and accommodating it would require special casing almost every step of arc land, make the workflow more complex for everyone else, and replace some errors with potentially confusing behaviors under normal use.

Awesome! I'll keep this around as context for getting the root issue fixed. Thanks for the report, and let us know if you run into anything else.

Another possible workaround would be to go find the credential in Passphrase and just update that, assuming the rest of the configuration is correct.

Er, sorry, had the wrong URL in the previous comment. Should be correct now, I think.

If you manually go to /diffusion/COLP/edit/ does that work?

We should improve the error handling behavior here. Because this is a clustered repository, we're failing more abruptly than we would with a non-service repository, but we should make the behavior more similar.

I am not asking for "support" per se, so I am not sure the referenced link is applicable for this task.

Why do you have a memory limit configured on the CLI? Do you legitimately want scripts to exit after consuming 128MB of RAM, or is this just a default you haven't changed?

Type Depends on D123. in your summary. See T5132.

Yeah, basically strncmp has worst-case runtime O(length(needle)) while strpos has worst-case runtime O(length(haystack) * length(needle)).

Try with a 10MB haystack.

See also:

Sorry, we do not support third-party application development. See T5447 for discussion.

Comcastic!

(If you immediately get another error, there's some more serious problem with state tracking. This usually means you imported/exported awkwardly or mucked with the data somehow, and recovery depends on exactly what state you're in and how you got there.)

(If you immediately get another error, there's some more serious problem with state tracking. This usually means you imported/exported awkwardly or mucked with the data somehow, and recovery depends on exactly what state you're in and how you got there.)

Delete all the text in 20150609.spaces.1.pholio.sql (but not the file itself), then run bin/storage upgrade again.

Ah, thanks! I think we're probably in fairly good shape once everything is properly documented so I'll plan to close this out and we can look at placeholder results in the future if there's a compelling need for it from somewhere else.

I'll add one thing to Evan's comments there, which is that it would be useful to be able to create a test before the results are available. That way reviewers can see that such and such tests are still running and their results are pending.

See T4213 for "we change CSS all the time and your stuff will break every few months if you mess with it".

Can you give me a better idea of what these huge, extremely similar projects are? I can't come up with any guesses from my experience, and the categories don't precisely sound like operations or software engineering. I've never heard the term "Fitout" before and Google is only giving me hits in the context of interior design.

I pushed this host, should be all set now?

Broadly, we're much more able to solve problems if you describing the problem you're facing rather than just the solution you're interested in:

There's some prior discussion of something similar in T7190. Is your use case a lot like that, or a lot different, or somewhere in between?

Put another way, there is no scenario where running bin/remove destroy is desirable:

It is difficult to concisely communicate what bin/remove destroy does.

Whoops, that's half a draft. Ignore that, I'll write a proper version...