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.

Can I make a question?

1. Install Phabricator at the version noted above.
2. Import a GIT repository via observing a URI.
3. Note the reference HEAD -> master link broken on latest commit.

Please provide reproduction steps, we don't accept bug reports that ask us to go look at their server.

Hi I recently started experimenting with phabricator with my team and stumbled on this issue.

The in-diff issue is described in T11482.

We once rendered these renames like this:

new/path/to/file.c
  Moved From: old/path/to/file.c

Personally I like that, I think a compromise to make it easier to consume, would be to try and group the moves together and showing the relation, for example
now:

a ->
b ->
a <-
b <-

to

a ->
a <-
b ->
b <-

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

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?