Trac Sprints

Next Sprint

The next sprint will be at ​PyCon 2008 from Monday, March 17th until Thursday, March 20th. There will be an introductory session on Sunday, March 16th at 4:40pm CDT.

Sprint Ideas

• Work on 0.11 Release - Should have a 0.11b2 by then. +11
• Get sandbox/testing ready to merge
• give evil_twin a brain
• Work on sqlalchemy branch _{(but see caveats below — cboos)} +1
• Internationalization
• Pluggable user-directory provider
• Fix ticket delete — delete ticket changes

Eli Carter

• Get my "mergebot" stuff on ​t-h.o

John Hampton

• Port ​TracBlogPlugin to 0.11
• Work on Tags based permission policy plugin

John M. Camara

Not sure what areas I will work on during the sprint but I have interests in

• SQLAlchemy migration
• Support for multiple work flows. i.e. a work flow per ticket type
• Ticket hierarchies. i.e. support for parent/child relationships between tickets
• Investigate plausibility of combining milestones and ticket hierarchies. Not really any difference between a parent ticket and a milestone. May want to display parent tickets slightly differently than child tickets but the underlining data models would be the same.
• project planning - discuss future releases, milestones, review open tickets, etc
• Making UI changes myself is not my cup of tea but would like to document suggestions in improving
  • Web admin related to group and permissions
  • UI for work flows
• Improve documentation by including additional examples in the following wiki pages
  • TracIni
  • WikiMacros

patches #5608

AlecThomas

• Add support for deploying cgi/fcgi/wsgi scripts to trac-admin.

---

Notes

SQLAlchemy

I'd hate to see a lot of effort spent on the superficial aspect of the SQLAlchemy port, because that could be eventually wasted if we don't first answer the more fundamental questions. The data model creation part has been done (I think), we know porting the statements is doable (only lots of work) - what we don't know yet is if the benefits brought by SQLAlchemy on the infrastructure outweights the disadvantage of adding yet another required dependency.

So I'd welcome any progress on the SQLAlchemy integration, but it has to address the right questions:

• better pool handling?
• no new / different multithreading issues?
• evaluate the impact of SQLAlchemy on all the open issues for PostgreSQL, SQLite, MySQL i.e. does SQLAlchemy help, make things worse, is indifferent to the issue?

— cboos

I also wonder whether it would be better to move to Elixir now instead of plain SQLAlchemy. Makes the models much cleaner, IMHO. — djc

IMO it would be better to stick to straight SQLAlchemy rather than use Elixir. You never know when some other declarative layer built over SQLAlchemy comes around and replaces Elixer as the de-facto standard. Also, I don't believe using straight SQLAlchemy is going to add that much of a coding burden over Elixer and it has the added benefit of scaling better. - Camara

I have to agree with djc. Elixir mitigates most of the tedium of using SQLAlchemy, leaving just the awesome. — AlecThomas

Strange, calling adding SQLAlchemy and its dependency a disadvantage, but then advocating putting Elixir on top of it. Elixir looks like Django-syntactic sugar over SQLAlchemy. Doesn't make me hot or cold. — asmodai

Notes from the BoF

• Ability for administrators to "uninstall" plugins, dropping tables, etc.
• Cross-project reporting? What do people use?
• What's the deal with multi-repository support?
• Let plugin test suites be run with Trac.
• One-click plugin installer would be nice. Also TH could then easily track usage of plugins.
• Timing and estimation seems very popular, but the plugin is not great.
• Ticket dependencies are very popular too.