Make the timeline threaded

[r.sokoll@…]

From a little dicussion in ​trac-users, it came out that it might be a good idea to have a threaded timeline with the possibility to expand/collapse threads. This would make the timeline less noisy, especially on busy timelines.

What I mean here is something like (expanded view):

04/07/10
  Ticket #123 created by
  Ticket #122 created by
  Ticket #100 closed by
    Ticket #100 updated by
      Ticket #100 created by
  Ticket #121 created by 

Or a collapsed view:

04/07/10
  Ticket #123 created by
  Ticket #122 created by
  + Ticket #100 closed by (2 more events)
  Ticket #121 created by

And if you click on the plus sign at #100, the view gets expanded. We already have this in TracBrowser.

The user should be able to configure this behaviour in her/his preferences.

[Christian Boos]

0.13 might be the milestone in which this gets implemented, and although I already expressed support to the idea of a threaded timeline on the Trac-users list, I can't promise anything for 0.13.

We'll try to be much more conservative about assigning tickets to version milestones, for the next milestones. When one of the Trac developers assigns it, it should really mean he's reasonably confident he can do it. Otherwise, when we simply think it's a good idea and it would be nice to have it as early as possible, we'll use the next-major/next-minor… milestones for that.

This workflow will help us to avoid having to constantly move tickets from one milestone to the next, and at the same time have a better overview of what's really planned for the immediate next release.

[Christian Boos]

For folding changesets, they could be grouped as being part of the same push operation, assuming the hooks would notify us from an incoming sequence of changesets. It seems the trac-admin changeset added command already has the adequate call convention:

changeset added <repos> <rev> [rev] [...]

    Notify trac about changesets added to a repository

    This command should be called from a post-commit hook. It will trigger a
    cache update and notify components about the addition.

To which we should perhaps add the user who did the push. We would then need to have a way to convey that information further.

See also: ​Mozilla's Mercurial pushlog, ​SonicHg's pushlog, ​Gitorious