It is expected that taskmasters will exit and restart after an unexpected failure, but this should not trigger setup warnings. I'll see if I can reproduce this.

This might be the same as T12302, but I'll see what's going on.

Persistent chat was originally a separate column (so it didn't overlap with anything on the page) but was brought into the main page recently.

Yeah I'll take it, pretty sure it's my fault.

I think this is probbbbbbbably an actual bug unless I'm totally out of it -- possibly my fault from D17372.

No.

I believe this is effectively resolved now -- we're running all the daemons on multiple hosts on secure. There's remaining followup work (T6768, T6615, T10753, T10754) but I think the core is in reasonable shape.

T11708 has almost nothing to do with this, but the fix for this will rewrite the code that's running into issues and probably moot them.

I'm just going to merge this into T12115, which isn't really related, but will rewrite this code and probably "fix" this, since a reproduction case seems elusive.

This could probably be built with RRULEs now, but we don't currently have use cases / plans around a general-purpose cron-like tool.

Use cases seem to be fairly well covered now.

This is 2+ years old and autoscaling probably covers it now. T5401 is probably a more tangible attack on this.

This got a little more work when clustering was written but it's essentially a log of two-year-old ghost sightings at this point and not actionable.

I guess this one can live for now since that's reproducible/actionable.

Probably a dupe of T11708? I'm just going to kill this one since it's old as dirt.

I believe this was likely resolved by D16460. This (binary transport over Conduit) is still a problem in general, and T5955 is the general remedy, but diffusion.rawdiffquery specifically now returns data via Files.

I think it is likely that this was resolved by D17123. If it wasn't, we don't have a reproduction case anyway so we can't move forward. I'm going to call this one dead until more information turns up.

We were never able to reproduce this convincingly and as far as we know the reporting install no longer uses Phabricator, so I'm going to close this out.

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?