On Thu, Jul 08, 2010 at 01:16:36PM +0200, Felix Schwarz wrote: > One thing that hold me back of doing that with the ticket system so > far was that I had the impression that my patches would be rejected > anyway as core trac does not *want* to go in this direction.
And here is a key point, of course. My objection is that there is a huge collision with this policy and the planned feature scope. > As Noah said, we're living in an economy of time. I'm willing to > spend some time to implement something incrementally and for some > core ticket parts I pretty much know how this could be done as I've > already done that. As I just outlined in previous post, I really don't think the system can be replaced as a whole, with the best solution, using the incremental approach. Granted, many optimizations can be done at much lower cost, but will take much longer time to reach the value of a rewrite (speaking long-terms). This is the critical part for the core team, of course. IMO, you should consider the relational approach. You can *certainly* do incremental improvements with it, without doing a complete rewrite. But it's probably not something I am interested in contributing to, unless, of course you are looking for concrete model design work for particular subsystem planned for replacement, in which case I will gladly help out! :) Terje -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to trac-...@googlegroups.com. To unsubscribe from this group, send email to trac-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
