TracDev ToDo List

Keep an eye on contributions

• #1942 has been revived recently, review the patches
• interesting patch on #10425, need to follow-up on #10178 as well

• Tickets with patch keyword (initial patch proposed)
  

By milestone: 1.7.1 #1660,​13273, next-dev-1.7.x #4519,​7628,​7820,​8069,​9222,​10040,​10948, next-major-releases #3332,​3519,​4080,​8509,​9643,​9648,​10178,​10665,​918,​1804,​2695,​3273,​3584,​3689,​4549,​4612,​5246,​5670,​5997,​6492,​6986,​7026,​7055,​7573,​7793,​7850,​7872,​7898,​8165,​8219,​8541,​8640,​8945,​8961,​9638,​9646,​9674,​9967,​9979,​10201,​10396,​10413,​10425,​10736,​10755,​10983,​548,​6118,​6128,​8135,​8681,​9125, next-stable-1.6.x #4245,​7687,​6002,​6367,​6682,​8700,​9140,​10884,​5820,​8829,​13346, plugin - mercurial #8417, undecided #10203,​10640,​11338, #12453

• Tickets with review keyword (patch or branch "ready", need some review):
  

By milestone: next-major-releases #9643,​8541,​12162, next-stable-1.6.x #6367,​9771, translations #5473, undecided #10640, unscheduled #2299,​9082,​4329

• Tickets with needfixup keyword (patch or branch already reviewed, need some further work):
  

By milestone: next-major-releases #7872,​8961

• Tickets with no milestone set (need to be triaged) {20}:
  

0 new this week, 23 older and 0 with patches

We should strive to keep the number of untriaged tickets older than a week down to 0!

Next Releases

Transition 0.13 → 1.0

Prepare the transition before any pre-release.

I doesn't make sense to have a 0.13-beta1 then a 1.0-beta2, directly go for 1.0x.

Trac 1.0

We should focus on polishing the major new features.

Check what remaining changes might benefit from a major release:

• jQuery upgrade (#10165)
• move svn support to tracopt

Finish tickets which are "mainly done":

• #10594
• #7145
• #10313
• #10012

Documentation:

• Batch copy of wiki pages this time? (#4412) Before having to copy everything again by hand…
• Update the TracL10N documentation for new-style Transifex

next-major-0.1X → next-devel-1.1.x

Wiki

• #1132, #3021 and GenericTrac, attacking it from the wiki side…
  • #31 and #886 (experimental repos:ticket-links)
  • TracDev/Proposals/MultipleProject
• #4431 and related wiki improvements (experimental branch ​http://github.com/cboos/trac/tree/wikiparser)

Version Control

• CachedRepository.get_path_history
• show merge changesets in revision log (#3236) hg log --follow-first (check, isn't that already done?) no, seems like follow-first is meaningless; git log --first-parent support
• Hg: add basic support for cached repo (#8417)
• More revisions available link at the bottom of revision log, when viewing a partial revision set (#4854 actually)

General

• #2456 - users, #5648 - groups
  • i18n
    • perhaps translation for workflow status and action names (#5441)
    • early loading and caching of catalogs (was discussed in #9439)
• Help delegator (ticket:2656#comment:26)
• #8507 improve explicit gc
• Template: replace support for Clearsilver with support for Jinja2 - TracDev/Proposals/Jinja (less urgent now that we have a good Genshi 0.6 release)

Ticket

• Custom Queries: #7026 - redo with jQuery UI drag'n'drop?

• sort order of tickets in search results: I expected this to be based on the most recent modification time first? It's seems it's creation time first…

Miscellaneous

• Verify this one, not sure yet it's a bug which is still present or a transient error that happened in between updates:

  2010-02-26 19:24:14,087 Trac[changeset] WARNING: Diff rendering failed for property svn:mergeinfo with renderer SubversionMergePropertyDiffRenderer:
  Traceback (most recent call last):
    File "build/bdist.linux-x86_64/egg/trac/versioncontrol/web_ui/changeset.py", line 798, in render_property_diff
      options)
    File "build/bdist.linux-x86_64/egg/trac/versioncontrol/svn_prop.py", line 297, in render_property_diff
      all_revs = set(repos._get_node_revs(spath))
    File "build/bdist.linux-x86_64/egg/trac/versioncontrol/cache.py", line 290, in _get_node_revs
      slast = '%010d' % last
  TypeError: int argument required
  

• In TracInstall#GeneratingtheTraccgi-bindirectory, there's the mention of chicken/egg problem with trac-admin deploy. I've been bitten by this as well and I think we should support a direct trac-admin deploy <target> call syntax, i.e. without the need to specify a (dummy) environment.

---

To editors: this is not the place where to put your favorite ticket (see SeaChange/WhatUsersWant instead); this page must be kept short and is mainly for improving the clarity of the ongoing development activity in the TracTeam.