> -----Original Message----- > From: [email protected] [mailto:[EMAIL PROTECTED] On > Behalf Of Endre Bakka > Sent: Thursday, June 19, 2008 3:18 PM > To: [email protected] > Subject: [Trac-dev] Re: Is Redmine a better Trac? What's gone wrong > with Trac? > > > > 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. > > I find it very very hard to believe that the vast majority don't need > subcomponents. And if some don't want them, they won't see them anyway. > If > you don't add a subcomponent in the admin window, they don't have to be > showed elsewhere neither. Non-intrusive = all good. It's there for > those > who need it, and not in the way for those who don't. When you need it > and > it's not there and you have to hunt down a plugin from track-hacks, > install it and worry about maintenance, it get's in the way.
Please read my blog post. Saying "plugins are hard to install" doesn't mean things shouldn't be plugins, it means we should make installing plugins easier. Fixing the right problem benefits everyone in the long run. As for worrying about maintenance, most plugins update much faster and more frequently than Trac itself, so I'm not sure what you think you will gain. > > Apparently you didn't read what I said. We specifically avoid this > > model. It > > leads to poor design and even worse implementations. > > Yes I did read and understand you, I'm just arguing that you're wrong > ;-). > So does a lot of brilliant developers (have you read that book btw?) Yes, on several occasions. I just disagree with parts of it for user-facing software. > Also, you say you avoid this model. Tracs homepage states otherwise. Do > all core maintainers agree on this? In that case, changing the homepage > is > in order. If not, I think this is the time to voice your opinion. Other developers have been fairly quiet on this thread, but I would never presume to speak for them. > >> 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. > > I would not call the linux kernel, git and firefox for giant messy > piles > of garbages. But I have a feeling we disagree on many things. You clearly have never read the code for any of these. Go ahead, I'll wait. Let me know when they figure out how to make gecko usefully modularized. Last I saw they decided to give up for a while because it has so much global state scattered everywhere. Git is a seemingly random assortment of C, shell scripts, and perl. The developers actively opposed having a single API (libgit) because they felt it would be limiting. The linux kernel has more legacy crap in it than most software will ever see. When was the last time you wanted to use a DECNET DNA network? So yes, this are all hugely disorganized and poorly designed projects. --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 -~----------~----~----~----~------~----~------~--~---
