Hi, On Jun 19, 11:45 pm, "Noah Kantrowitz" <[EMAIL PROTECTED]> wrote: [...]
> 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. How do you know? I often read this statement here or on trac-users for various different features and I would really like to know what are the reasons for this assumption. Anyway, I'm just a user of Trac and haven't contributed anything to Trac yet, but I followed many discussions the past year on Trac's mailing-lists. I really don't understand why Trac isn't shipped with a package of commonly used plugins (AccountManager, IniAdmin etc.). Or maybe it would be enough to provide and maintain this package on t.e.o to ensure that this package always works with the actual release. Especially for AccountManager again I really don't understand, why this is still a plugin. For nearly every login problem raised on trac- users, the answer is "Install AccountManagerPlugin". Why does a plugin provide this really basic functionality? Just my 2 cents Simon > > > > > 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 -~----------~----~----~----~------~----~------~--~---
