Developers' Corner

A blackboard for ideas related to future directions

This page is for drafting long term ideas and share the vision the Trac developers have about the future directions of the project.

See also those related resources:

• for the actual coordination of on-going tasks, see TracDev/ToDo.
• have a sneak preview of cboos' next steps
• see the topics currently discussed for the next major versions 0.13 and 0.14.

Thanks to our editorial freedom, this page has also been hijacked by potential contributors asking questions or raising concerns… for example:

Need:

• Tutorials
  • cover basic things like - read option, show page
• Debugging Tools
  • request tracer - see how request is going to be processed (or was processed), which extension points were polled in which order and optionally with which params

Development Process Issues

Regarding High Level Observations points raised on the SeaChange page:

1. Core development has stagnated
   Probably true, we need more people to actively care about the project. How?

   Comment: Just look at the history of #2456. People cared, wrote patches, discussed the issue. But in the end nothing changed despite the fact that trac doesnt adhere to its design principles in that area (Users not managed via pluggable Components/Relations) The ticket is 4 years old. There are few comments from team members and virtually no information what problems prevent this to move forward. People got frustrated, wrote competing implementations/plugins or gave up and moved on. I think it's worth analyzing what went wrong here.

   1. lowering the barrier to entry
      We could achieve this by providing better docs, API docs , cleaner and simpler code (ticket:10125#comment:15 has some good hints about this)

      Comment: When I started looking into Trac it kinda felt like development documentation is somewhere between minimal and completely missing for some areas, but I personally find the source code quite useful (its well documented and I found everything I needed so far). Yet I do think that setting-up API documentation can really help developing for Trac, while it shouldn't take too much effort - there must be plenty of API documentation generators for Python - shesek

see TracDev/ApiDocs…

1. motivating people to jump over the barrier
   
   • the great new feature!
   • nice stuff that really makes Trac stand out of the competition
   • cookies!
2. Some ideas which may be completely off the mark…
   • ?? Use more standard libraries. Templating has moved to Genshi, but maybe SQLAlchemy for DB backend?
   • ?? Highlight issues that should be easy for new people to fix
     • see ?status=!closed&keywords=~bitesized
   • ?? Google summer of code mentoring (requires time though)

2. Core developers do not or cannot commit a lot of time to the project
   Whip them? Otherwise, see 1.

   Comment: In theory they don't need to, if the community can write patches and test them, then all the core developers need to do is commit to svn.

Aggregating random changes is not going to work. We need a plan, a global vision.

3. Frequently requested features do not get implemented
   Big features (e.g. MultipleProjectSupport) first need to have a developer really needing the feature, as it can't be done without some kind of deep involvement.
4. Release cycle is way too slow
   (need a picture showing Release History)
   I proposed something with intermediate point releases, see ​googlegroups:trac-dev:7f875005134cd355. We should actually do it. Current idea is to shorten the development cycle of major releases, see ​googlegroups:trac-dev:6823a7fa94bb0392. This is still somewhat complementary to first idea exposed above: if a big feature doesn't make it for a release, it should simply wait for the next one instead of delaying it further. This implies merging a feature late, once we're sure it can be finished. Late merging has its own drawbacks, which could perhaps be mitigated by the use of temporary integration branches.
5. Zero chance of a plugin getting into the core
   Well, WebAdmin was integrated. There was some attempt to do the same for ​AccountManagerPlugin (see also WhatUsersWant), but see 3.
   • see again ticket:10125#comment:15: getting some parts of the ​TH:XmlRpcPlugin into core?
   Note that some plugins will never be integrated or even bundled, due to licensing issues (TracMercurial and ​GitPlugin).
   

Can someone explain the licensing issues here? I used to be a Trac user, and for me, the main reason I don't think of using it now is that my default option is Github. And I wouldn't think of using a SCM that wasn't distributed. For Trac to remain relevant to me, it needs to support Git or Mercurial as natively as it supports SVN. (Ie. not need me to install and manage a plugin).

As I understand it, we can't integrate the TracMercurial plugin because we're using its internal API ("linking to it"). Doing that would force us to distribute Trac as GPL as well, something we don't want to. The git plugin could be different story, as it uses git via its command line interface, so if HvR was to relicense his git plugin under a BSD like license, we might consider it for inclusion (probably below tracopt.versioncontrol.git.). Same thing could happen with a rewrite of the Mercurial plugin to use its command line interface, but that would be silly, of course ;-) The other option to make git and mercurial stand on a more equal footing than svn would be to extract the svn support in a plugin, or at the very least move it to tracopt.versioncontrol.svn_fs.* (svn_fs because having one day a .svn.* backend based on the command line would be an option) — cboos

6. Features that users think should be "core" are not
   Since 0.12, there's a new tracopt. package hierarchy, for bundling components that are not enabled by default. This makes it possible to have some room between strictly necessary for almost anyone using Trac (trac.) and optional, must be 3rd party.