On Jul 28, 2009, at 3:44 PM, Christian Boos wrote:
> > Leonardo Santagada wrote: >> How can I help with the SQLAlchemy port? Is it scheduled for any >> particular Trac version or even been discussed about including it in >> trunk? > > That port was proposed several times, but it's still not obvious yet > if > this will bring any improvement to the current situation. It's a lot > of > work to do the conversion. So this is a kind of chicken-egg situation: > it's not really possible to commit ourselves to do the switch without > knowing more about the impact it would have, it's hard for someone to > invest time on this knowing that all that work can eventually be > thrown > away... > > Put it differently: what do you expect from this switch? I answered that on another email (just seconds ago) but the idea is better and easier interoperability with other databases and better support for pooling is a start. For the future, being able to extend trac by extending the models directly more like Roundup than by ticket- custom seems interesting. One example would be how easy it would be to express that the values of a combo on the ticket come from SQLAlchemy. >> And what about account manager/ldap support? >> > > John started an integration effort, the last changeset says: > > Initial merge working. Removal of registration and email verification > needed. Lots of other cleanup needed > > So I guess that's a start ;-) > See http://trac.edgewall.org/log/sandbox/accountmanager Cool I will look at that branch. >> Those are to me the two things that bug me about trac (besides >> multiple repos that are being worked on and some cosmetic changes >> regarding the UI). >> > > #2086 is certainly one of the most anticipated feature, it's > progressing > well, though we're not there yet. Testing and feedback welcomed ;-) > About the cosmetic changes, they count as real tickets as well. We're > definitely in need for some CSS expertise and there are lots of > usability and layout tickets awaiting contributors, don't hesitate to > help there as well. This is what I'm really interested in Usability both of trac itself but also of the API for people extending it. Sometimes I find it a little hard to find what is the best way to extend trac, and the users of my deployment (+/- 200 employees) find trac confusing to use at parts (specially the query/reports part). I will look at tickets and see if I can find a place to start :). Thanks a lot for answering my mail. -- Leonardo Santagada santagada at gmail.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
