@rrfeng: You already brought this up in T11680 - please see and follow the reply you received there. No need to add comments in numerous places to decentralize any conversations about the (currently unclear) underlying issue you're perceiving. Please stick to T11680 - thanks!

I think the "graph trace" UI is not suitable for task graph.
The most scene which has problem is 1 task has too many sub tasks. And then the graph-status takes too much spaces of the page(It is so wide).

Some somewhat-good news is that Google Calendar just gives you an .ics blob of garbage to describe recurrence rules:

Things don't look promising.

I think we should be able to accommodate that fairly easily.

(comment posted twice for some reason)

I thought I'd throw our use case in here in case it helps:

More generally, here's how I'm planning to model imports, which seems largely consistent with other systems:

Yeah, I fiddled with that but didn't immediately have any luck. It's possible that there's some complex condition like non-self organizer + non-self sender or something. If it only requires non-organizer, it should already work today (e.g., on this install).

@epriestley in that post you linked there's a comment:

I'm having trouble making GMail provide a reasonable pathway forward for getting .ics events onto Google Calendar. Ostensibly this just works:

ICS primarily identifies users (organizers and attendees) by email address. Phabricator does not normally disclose email addresses, and I don't want to let someone scrape every email address out of Phabricator by inviting every user to an event and downloading the .ics.

We've been testing the LFS support for use with our game repository. Using a relatively small test repo we've had great results and will be going ahead and trying to use this for our main git repo (a new copy with an empty history that is). So thanks for getting support in! This is a killer feature as far as game dev is concerned.

I was looking for similar functionality (publish the state of some external system on a panel) and instead of updating the entire panel I think it would be nice to use Phlux or Paste:

Well, "trivial" might be a little ambitious.

Ah, thanks! That's a bug which we hadn't run into yet, but it's trivial to fix.

When tasks are mentioned in calendar descriptions (afaik very common for meeting agendas), the usual "<user> mentioned this in <place>" does not show up on the task. Is this part of the unprototyping effort?

I'm super excited about this feature.

How difficult would this be for someone to implement / does upstream have an implementation timeline for this?

How would we distinguish between source/android/browse/carafe/ being "browse branch carafe of repository android" vs "browse the home page of repository carafe located at path android/browse/" in such a scheme?

Shortname is already used for the shortname.git portion of the URI. Would it be out of the question to allow a separate path to be configured, perhaps also including nested directories?

That looks really useful. With such a view, perhaps the existence of inline comments that are Not Done can be a blocker for arc land.

See T7924 for current Calendar roadmap items.

So CalDAV support (for iCloud and others) is not planned? Google Calendar API is propritary while CalDAV is a standard. There is a really good php implementation of client/server and card parsers: https://github.com/fruux/sabre-dav
@devurandom yes that is true, and it is really simple using save/dav.

I've not looked into the details of the implementation you started, but because it's gettext I thought maybe some links wouldn't harm:

• https://blogs.gnome.org/mclasen/2016/07/21/using-modern-gettext/
• http://nedohodnik.net/gettextbis/
• http://laxstrom.name/blag/2013/11/20/review-of-gettext-pot-file-format/

T5088 is a possible use case (report if the current revision needs an update), although I feel like it's a bit flimsy.

To summarize discussion from elsewhere: it isn't clear to me when this is better than other tools -- including arc browse D123, which already exists.

I don't want to continue expanding the existing "mail tags" system in Settings → Email Preferences. See some discussion in T11337.

In T11034#186209, @epriestley wrote:

The dialog can be resized by dragging the lower right corner.

What about show only active projects in "Browse projects" window?

Hello! What about show only active projects in "Browse projects" window?

In T10939#176633, @Luke081515.2 wrote:

General question: Why is the owners option "Add as reviewer (blocking)" if an owner uploads a revision? I know that this is expected, but why? For example at Wikimedia we currently have the system, that every change needs a review from an "owner" before the patch gets merged, so it's not useful, if an owner of the package uploads a change, and no reviewers get added. Maybe the a compromise may be a setting, where you can choose, if a package gets added as reviewer too, if the author of the revision is an owner too? I think that would help all.

See T4788#184477 for current plans.

In T4788#185925, @CodeMouse92 wrote:

[...] Still, I think it would be pretty simple to just shut off the task graph (but not the list?) in those situations [...]

I definitely agree that in most cases, 100+ subtasks (especially direct subtasks) is better as a project. Still, I think it would be pretty simple to just shut off the task graph (but not the list?) in those situations if there is an exception that hasn't been thought of.

It might be useful if the dependency resolution was only two-levels deep. That wouldn't really solve the problem for extremely wide trees though.

In T4788#185851, @chad wrote:

If you have more than 100 subtasks, the task should probably be a project so it can be properly organized.

In T4788#185851, @chad wrote:

If you have more than 100 subtasks, the task should probably be a project so it can be properly organized.

If you have more than 100 subtasks, the task should probably be a project so it can be properly organized.

Also, before that is done, rather than showing "Task graph too large to display ..." message, have fallback to the old plain list of tasks. Therefore the information will still be available, but just simply not provided as fancy...