= The Trac development process == High Level Observations These are observations only on the current development process on Trac. No judgement is implied. 1. A lot of the current core developers do not or cannot commit a lot of time to the project. 1. Frequently requested features do not get implemented. eg. multi-project support. 1. Release cycle is ''way'' too slow. 1. Historically, there's effectively zero chance of a plugin getting into the core. 1. Features that users think should be "core" are not. 1. Many Trac tickets have gone stale and they could probably be closed. === 1. Core developers do not or cannot commit a lot of time to the project {{{#!div style="background:#efe" 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. }}} We need more people to actively care about the project. {{{#!div style="background:#efe" 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 '''15 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. }}} a. Lowering the barrier to entry [[br]] We could achieve this by providing better docs, API docs, cleaner and simpler code (ticket:10125#comment:15 has some good hints about this) {{{#!div style="background:#efe" 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 and TracDev/PluginDevelopment/ExtensionPoints. A practical course of a computer science student could be to analyze the sources and create an UML model and some UML diagrams of the whole project. This can highly increase the chance that people realize the architecture and are able to extend it with features like e.g. user management. There are some good community versions of UML tools around for free. - falkb b. Motivating people to jump over the barrier - the great new feature - functionality that really makes Trac stand out of the competition - monetary remuneration - donation mechanism a. Some ideas which may be completely off the mark: - Use more standard libraries. Templating has moved to Jinja, but maybe SQLAlchemy for DB backend, such as in [th:SqlAlchemyQueryMacro]? - Highlight issues that should be easy for new people to fix: see [query:?status=!closed&keywords=~bitesized] - Google summer of code mentoring (requires time though) === 2. 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. === 3. Release cycle is too slow [[Image(wiki:SeaChange/WhatDevelopersWant:trac_release_statistics.jpg)]] [[br]] (cboos) proposed something with intermediate point releases, see googlegroups:trac-dev:7f875005134cd355. We're actually going to do it, right after 1.0, see [gdiscussion:trac-dev:17DO_N1MM-A the whole discussion] and the [gmessage:trac-dev:17DO_N1MM-A/nbhupXw0NAIJ decision to go with 1.0] directly and from that point, have regular 1.0.x stable releases and 1.1.x development releases, until the cycle repeats. === 4. Zero chance of a plugin getting into the core There was some attempt to integrate [TH:AccountManagerPlugin], see also [../WhatUsersWant], but see also point 2: Frequently requested features do not get implemented. - 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, such as TracMercurial and [TH:GitPlugin]. [[br]] 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.`). Actually, the integration of Git support happened recently (see gdiscussion:trac-dev:hCwTylvQ_FU and #10594), just like described above. Same thing could happen with a rewrite of the Mercurial plugin to use its command line interface, but that would be silly, of course. \\ See #10411 for a reasonable alternative. Another 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// === 5. Features that users think should be "core" are not Since 0.12, there's a new [source:trunk/tracopt 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.'' === 6. Many Trac tickets have gone stale and they could probably be closed The currently [[TicketQuery(status=!closed,format=count)]] active tickets, often old and with inflated severity, give a false impression of the state of the project. Some very old tickets relevant to points 2 and 5 above could be closed as 'wontfix', perhaps with a note suggesting interested parties could write a patch and reopen the ticket if it is still relevant. Many others could be set to low priority and moved to the 'unscheduled' milestone to help reduce the clutter. Occasional ticket triaging is already underway,.