I believe I have the first part of this (restructuring the code into a more sensible Overseer > Pool > Daemon sort of thing) working, but it could use more testing. I'm going to see if we have anything else in Daemons that I can fix while I'm here to help me kick the tires a bit.

This request doesn't describe a root problem, just suggests we do about a thousand hours of work integrating with remote APIs. See Describing Root Problems.

Some possible approaches here:

There's also a bunch of the usual free-tier shenanigans on this host -- free instances with 1 user importing multiple large repositories -- but that's to be expected.

Here's an attempt to manually classify recent feature requests. I'm not sure how much value we're really getting out of this channel except from users who are already part of Community:

Unfortunately, we haven't received enough information on this to move forward. See Contributing Feature Requests and Contributing Bug Reports if you'd like to try filing a new request.

The in-diff issue is described in T11482.

I'm not sure I understand what changes you're suggesting.

This is currently the scalability and stability bottleneck for deployments, but should be relatively easy to fix.

(For anyone following along, some additional discussion of clustershell in T2794.)

We'll open source everything that's general-purpose. (Currently, the only piece that's closed is the "plan" for Phacility deployments specifically. Since we don't have a generic "SSH" style plan as a starting point yet that plan is currently important, but we'll write generic plans or a general plan-executor or something eventually.)

I believe we only get it wrong in the very specific case where you're attending a "Busy" event and an "Away" event at the same time. We'll show the dot color for whichever event started first, so if the "Busy" event started before the "Away" event you get an orange dot instead of a red dot (if the "Away" event started first, we show a red dot, but that's the right color to show).

You should already be able to use custom forms to limit access to advanced fields by user, as we do on this install. If you (a user who is not a member of Community) try to create a new subtask here, I believe you will find that you can not access fields like "Assigned To" or "Priority". However, members of Community can.

It looks like clustershell is doing something pretty similar to Hypershell/Phage in its "gateway" mode (but it looks like it can't bootstrap itself and doesn't have a web UI).

T12278 suggests that "sprint tasks" are being used in this workflow -- not milestones -- and "backlog tasks" are being used -- not columns. But this task also mentions columns and workboards. A more detailed description of your workflow would be helpful in understanding where the intended tools (milestones and columns) are falling short.

Why do you create backlog tasks or sprint tasks instead of using Columns on Workboards or Milestones in Projects?

I don't think this is necessarily unreasonable, but I'd like to see significantly more interest in it from other installs before we pursue it.

Unfortunately, this doesn't seem to be moving toward an upstreamable feature request which completely describes a root problem. I'm not sure how we can make what we're asking for more clear. We've already spent a significant amount of time on this and need to move on to other things.

This has been live for a while now.

This has seemed stable for a while. We've fixed a few stemming issues and have T12137 and some other followups outstanding, but these generally are not issues that are fundamental to InnoDB Fulltext.

I think we mostly managed to get installs through this.

This has now been live for a while without anyone hitting real issues other than the minor hiccup in T12090. T8475 is an eventual followup.

This has been live for a couple of weeks and I don't think we've seen too much confusion from users.

I think D17374 covered everything I wanted to cover.

See also T12079 and T12219, although I'm not sure if either of those are duplicates of this.

The point of my comment was that as someone familiar with KDE, which is broadly a project with a somewhat-similar application structure and somewhat-similar application names, you should reasonably be aware that what you are asking for is not likely to be trivial or straightforward.

See T10622.

I find it noteworthy that this request comes from KDE, a project which ships a large number of applications with nonliteral names featuring "K" wordplay ("Konversation" instead of "IRC Client", "Konqueror" instead of "Browser", "KCachegrind" instead of "Graphical Frontend for Cachegrind, a Cache Profiler that is part of Valgrind, a Profiler Suite With An Unfortunate Nonliteral Name", and so on).

We're currently at ~82% cluster fullness which makes me slightly uncomfortable, but I'm not going to add more hardware quite yet since I think I can probably get "scale to 0" into production next week. If it's more involved than I think I'll likely put shards 017-020 into production in the next week or so.

Can't the same tricks used to make a single web server handle multiple instances be used for the daemons?

Yes, our expectation is that email solves the problem of notifying reviewers. If email isn't solving this problem, we'd prefer to try to fix that rather than add features to support a workflow where you manually copy-paste links into a Slack channel, since this is a fundamentally narrow, unscalable workflow and the feature isn't practical to implement in environments where arc is run on a remote host.

I'll just undo D17361 for now since the "MMMMMMMMMMMMMMMMM" thing is only a theoretical problem, and we can think about this more carefully outside of the context of a release cut.

What are two other ways we could solve the problem you're running into?

This is still a shallow ghost of Hypershell, but I successfully deployed secure with it:

As far as "opt-in", are you mostly concerned about performance?

(I'm not sure how "Compatibility Mode" and the DOM inspector are interacting, so maybe I'm just using it incorrectly.)

Here's the note in PhabricatorPeopleQuery about this:

I don't think this is worth bringing upstream. It very occasionally saves users one click on an otherwise straightforward workflow, but requires significant complexity and maintenance from the upstream.

According to compatibility mode on my machine (Windows 7, IE 11, in IE10 mode), there is no crumb bug in IE10 if float: left is removed. This isn't consistent with T5902 or with other results I got (e.g., this thing says there is such a bug).

Are you OK with this plan?

I made some effort to fix this, but without much headway:

D17374 makes hovercards a little bit more clear too, although that might get some design feedback still (see "Horse" here, for example):

In the future (T550) we plan to allow arc commands to use an SSH key. I'm not sure if that will reduce or increase confusion.

You should be able to can arc install-certificate --conduit-uri=https://whatever to install a certificate for an arbitrary install with no other configuration.

What is your use case for API access to notes?

D17373 should fix the typo.

Thanks! Your reproduction instructions were extremely clear and made hunting this down straightforward. D17372 should resolve this.

I gave the goat some leaves to eat because maybe goats eat leaves?

Those are old now I guess, I'll file something to see if @chad can fix it because I am not licensed to pixel.

Well by the time you divide false into 3600 pieces you can't have much left!

See LICENSE for license information:

Recently, we've started seeing a handful of attacks where human users appear to read a discussion, formulate a human-sounding, contextual reply (e.g., discussing the thread topic in what appears to be a human way, just with a very shallow understanding of the issue), and then include a link to a site offering various services (mostly essay writing?) in the footer.