Just tested this out with having global menu items of Create Task forms and Projects, each which are only visible based on some policy - looks to not have any issues hiding/showing based on those policies. Thanks for all this, when I get these changes into production install I'll check for feedback but I'm anticipating it will be a smoother experience for everyone.

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.)

@cspeckmim Thank you very much for the help.

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 totally get the motivation to have a strong collection of highly integrated tools which all work together seamlessly and provide a value that is larger than the sum of it's parts.

Note that I'm not asking for this to be done for everyone, by default. Rather, I want this to be an opt-in feature. I imagine this is also what the people who voted for the question on StackOverflow have in mind.

I was commenting on your suggestion to remove unwanted items from commit messages. It's a compliance feature for many businesses who need complete audit trails.

@chad sorry, but I don't follow, what has accountability to do with this?

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).

rare

Maybe my calendar setup isn't common but I usually have multiple overlapping meetings each week - I know others at the same company manage their calendar in a similar fashion.

An example.

No, I do not work together with @dtf, but I guess we have a similar workflow.

Thanks for your feedback! As you said it might be very complex to automatically sum up the points of all sub tasks. Of course this would be a very nice to have, but it was not my intention to request this quite complex feature. For us a "simple" UI change would be absolutely sufficient. It would be great to see the points of all sub tasks in the Task Graph at a glance.

Thanks for your feedback! As you said it might be very complex to automatically sum up the points of all sub tasks. Of course this would be a very nice to have, but it was not my intention to request this quite complex feature. For us a "simple" UI change would be absolutely sufficient. It would be great to see the points of all sub tasks in the Task Graph at a glance.

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).

Well, we do use Workboards and Milestones, Subprojects, but we'd like to have that feature. We have multiple custom fields configured, which are relevant to different parts of the team. I would like to be able to configure different sets of forms for those subteams so our newcomers don't break things they don't yet understand or shouldn't touch.

Some more shenanigans:

Cool stuff. I didn't see you already had made so much progress before I commented on T12218. You can safely disregard my clustershell suggestion.

@epriestley: Have you seen clustershell? It's a massively scaleable management shell with some pretty interesting features. Wikimedia operations are adopting it in place of a lot of dsh and saltstack stuff. From what I have seen it is a really solid framework to build upon.

I'm probably going to add a note to the dashboard dialog explaining home special casing better

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.

This request comes from me. I'm an individual. I have tagged it as KDE since I want to use it on the KDE instance of phabricator. I'm part of KDE, but I'm _not_ KDE.

@milianw Please keep in mind Phabricator is an enterprise tool, and the majority of installs (99%) are businesses who rely on the accountability we've built into the software.

See T10622.

Another reason for having a template:

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.

Fair enough - my team is odd in that we get a deluge of emails for diffs we're CC'd on since we own a platform for other developers, so we end up communicating diffs about the platform itself via chat instead of email. We should probably fix our email filters instead.

Then you wouldn't have to paste it into a window!

if only differential sent people reviews automatically.

M'Kay

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:

We generally don't consider a root problem of "Phabricator lacks feature" as a reason to accept a feature request. We still need to know the underlying problem.

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

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.)

NOTE: Since packages do not own paths exclusively, any user can create a package on / of every repository and be allowed to force-accept every package review because their "everything" package is now a containing package for all other packages. However, they could already just remove the reviewers, so I don't think this is important. We could add options to Owners (e.g., an optional whitelist of "Stronger" packages) or something to prevent this, but I don't plan to do this. Just fire anyone abusing it.

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).

https://msdn.microsoft.com/en-us/library/dn255001(v=vs.85).aspx

why can't you test 8-10? I thought you could do that with the inspection tools?

Are you OK with this plan?

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

just revert the change if you want... or fix

Thanks, Safari