Noah Kantrowitz wrote: > On May 29, 2008, at 11:52 PM, Culapov Andrei wrote: > >> Hi Richard, >> This is a nice feature to have in trac directly and I agree with you >> that it's not a very good solution to have a request filter and a >> stream filter for it. >> > > Uhhh, why not? The plugin system exists for exactly this reason. This > should be doable with just a request filter and some simple magic. > This sounds very much like a good case for a small plugin. I think > OForge and the link are bad ideas, plugins should be small and do one > thing (and do it well). That kind of huge collection of features might > be good for boxing up and shipping to people that want a turnkey > solution, but they aren't much use in the Trac community. >
Funny, at the same time I was reading the above, the following update came up on #31 (Ticket Dependency), about whether the MasterTicket plugin should be considered to be a "fix" for this issue or not: > Using third-party plugin for such essential functionality looks risky. > What about migration path and compatibility issues? There is no guarantee > on the future compatibility of MasterTickets and Trac. > Besides, MasterTickets looks quite limited. Trac is great, I bet you can > do better than that. > > I can't believe that Trac team avoided implementation of such essential > feature for so long (this ticket is 4+ years old). I love Trac but it's > unusable in large projects because of things like this. Sad. Nicely put, I can't agree more. Trac has a nice plugin system, and this has led some to think that every single feature can be implemented as a plugin. It's certainly possible from a technical point of view, but when the feature in question is a central one, or even more so, when the feature is actually more about fixing a (small) defective behavior (which I think is the case for this particular issue of "fields for missing dynamic vars", in a few mails above), creating a plugin for it is the wrong thing to do, IMO. Installing a system which requires a dozen of plugins in order to function properly is cumbersome. It simply doesn't give confidence in the system, and requires a good deal of expertise in knowing which plugins are really necessary and which should be avoided. So why would you ever take care to install a plugin for such a small defect like in this example, and face the associated risks? For the few people who would do it, you'll have thousands which will hit the problem in the "base" product and will just think it's not a well polished system (and they'll be right). I think the time spent in building such a plugin would have been better spent in writing a well-tested patch against the core product. The obvious advantage being that in later releases, no one will face the defective behavior again, and that the fix "melds" in, can be tested and verified against any other improvement to come. Also, more people get to know and work on the code, enabling its continuous improvement in quality. By doing it as a plugin, you're on your own and you build on a weak foundation instead of strengthening it. But of course you don't need to wait for someone to check in your patch, and you don't have to struggle with an unresponsive (if not hostile) development team, so it's the path of least resistance. I hope nobody gets me wrong: there's no questions that there are great Trac plugins out there, but those are rather adding new sub-systems, enabling connectivity with external systems or such things. But plugins which are addressing base functionality of existing subsystems or are merely there for fixing defects in Trac can rather be considered as "hacks". I never subscribed to this approach, but apparently I've been in the minority and I've given up to try to change this course of action. Now to answer the question "why has the Trac team avoided implementation of such essential feature (#31) for 4 years", it's quite simple: the TracCrossReferences effort which was started (3 years ago) to address that issue, among other things, didn't get any "traction", quite to the contrary, so it ended up in a branch which I stopped maintaining after a while. People here at one hand are striving for "perfection", so any incremental approach is considered very suspiciously, but on the other hand, as soon as it's outside of Trac, it's "free for all" and any kind of crude hack will do... No wonder some are answering "do it as a plugin!" to /every/ attempt to raise a discussion about improving the fundamentals of Trac itself, to the point there's almost no more development discussion on this list. Well, as you might have guessed by now, I've grown tired of this, and 0.11 will likely be my last Trac release, while I'm looking for ways to build an enhanced, more cohesive solution, in line with my ideas (this might succeed or not, but at least I won't have the feeling to bump into walls). -- Christian --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
