> -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Terje S. > Sent: Tuesday, July 06, 2010 12:31 PM > To: [email protected] > Subject: Re: [Trac-dev] Refactoring the Trac data model - relational > approach > > On Tue, Jul 06, 2010 at 12:16:37PM -0700, Noah Kantrowitz wrote: > > Again, you are talking about large-scale redesigns of all of Trac, > not just > > I have stated this unambigiously from my first post onward. If you > don't > like the posts feel free to score the thread or me down in your end. > > > the DB schema. This is neither here nor there, and unlikely to be > something > > that "Trac-proper" will consider without some pretty major > justification. If > > From my point of view, most of the ticket history on t.e.o is a > testament > that this is important to consider, if we want the product to flourish > long term. Most of the pages on the wiki that outline the future of > Trac > touch on very fundamental issues related to the modelling approach. > Understand that I am not attacking anyone, I am actually trying to > provide > some insight into *why* I think there already *is* major justification > to > change (is that hard to see?) > > > this is your goal, I would recommend forking (somewhat easier with > the git > > and hg mirrors running now) and start work on your changes. When you > have > > This is my goal, and I have already proposed a research codebase and > offered > my time. The question I'm trying to find an answer to, is whether Trac > is > a place I can contribute in a meaningful way. Now I know for sure you > are > not going to help out directly on a remodelling effort, but I'm still > hoping to gather support elsewhere on the list. You're probably right > in > that it's not going to work, but that's not stopping me from having a > go > at it. If you don't like it, score me down. If "Trac-proper" does not > like > it, I will shut up permanently.
This is neither required nor encouraged. I like seeing crazy new ideas tried out. I think it should just be done somewhere outside trunk. Heck, Trac itself arose out of wanting to redesign an earlier project tool. Rewrites (or large-scale systemic changes that are almost a rewrite) aren't necessarily evil, but the onus of proof falls on you to demonstrate you have a better way, not us to say you don't. I don't mean you should fork Trac as in start a whole new project, just copy the repo in github (which is called forking there) and start hacking away. If in a few weeks you think you have a much more elegant codebase, show us. You don't need to convince us of your design with words, you need to do it with code, and I am happy to be so convinced. --Noah -- 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.
