> -----Original Message----- > From: [email protected] [mailto:[EMAIL PROTECTED] On > Behalf Of Endre Bakka > Sent: Thursday, June 19, 2008 2:37 PM > To: [email protected] > Subject: [Trac-dev] Re: Is Redmine a better Trac? What's gone wrong > with Trac?
[snip] > Example: Just two weeks ago, Jeff Hammel asked about including > AutoQueryPlugin into the core, and he listed excellent reasons why it > should be included (I agree with all of them). Nobody answered his e- > mail. Lately we have been slightly more focused on final testing before getting 0.11 out the door. I do agree that feature should be added, in fact I thought it already was when I read the description. > Example: I wrote a patch for subcomponents since our company need this. > It > was ignored, both the ticket and an e-mail. I started asking around on > IRC > and was told it was clean, but way too large to include in the core so > I > should make a plugin. > > It took me a couple of evenings to implement, and 90% of the time was > spent trying to understand the Trac codebase so I was suprised when > told > it was too big (btw, "very high quality code" should be easy to read > and > understand - I think Trac still has some potential in that respect). > Well, > I wrote the plugin, but it was not a pleasant experience. It was much > harder to write, uglier, required a plethora of hacks due to > shortcomings > in the plug-in API, but I managed. I figured I would wait until 0.11 > was > released in case last minute changes affected my plugin. I've been > waiting > since December. I would rather see the API fixes in Trac core than the original patch. Subcomponents really are a feature I would rather see in a plugin, because the vast majority of people don't need or want them. > If I had gotten at least some feedback (even "your code sucks, clean it > up"), you would have seen many more patches from me. > > Suggestions: > - Live up to your mission statement. Do it the Bazaar way (see book for > details) > - Spend a bit less time on development and a bit more time at looking > at > other peoples patches that could be included. If you do, Trac will move > forward at a much higher pace. Users will be encouraged and more people > will join and write patches to include. > > Add functionality in baby steps. Some crappy support is better than > zip, > zilch, nothing. Users can give feedback (even in the form of patches) > as > you go along steering you towards a better product. Nobody (maybe > except a > handful in the world) are able to design and write the perfect system > without a couple of iterations. Everything can be rewritten (with a > proper > testsystem, without fear), and database tables can be altered anyway > you > like during an upgrade. Apparently you didn't read what I said. We specifically avoid this model. It leads to poor design and even worse implementations. > There is a reason why so many "other FOSS projects" work this way. It > is > more efficient. It is the Bazaar way. It also leads to giant, messy piles of garbage. It shows when something has been built with a single, coherent vision, and I think this is a large part of why people like Trac in the first place. --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 -~----------~----~----~----~------~----~------~--~---
