>> Noah Kantrowitz <noah <at> coderanger.net> writes: >> > >> > ... we really fix the problem with a 1-click plugin installer. I have >> been >> . >> > idea, they are just annoying to get working. Put this installer in >> Trac >> > core, and you get the experience I think everyone wants. >> > >> >> And it is called DLL, pardon, plugin hell ;-( > > Not sure who DLLs are related to this. DLL Hell is a loading paths issue ...
FYI: DLL Hell is primarily a DLL Versions Hell. > The current dev team is taxed enough as is maintain the current codebase and > adding new features we all seem to agree on. As code size increases, effort First, let me assure you that I do not try to bash dev team, on the contrary - kudos to all of you for the very useful product! The current team is too busy to add new features and do releases but, frankly speaking, the code base is too small to attract new members. All the main areas are taken and, as the recent disscussion on this list shows, you guys step on each others toes already. At the same time you are too conservative in extending the project and in adding new functionality which could bring in new members. This is not an easy problem and good luck in solving it - you are the only ones who could do it. > goes up in a very non-linear fashion. Two small codebases are much easier to > maintain and work with than one bigger one. > I would disagree on this one. There is no universal rule here. If the 'non-linear fashion' would be true, then the number of core gcc developers for example (in comparizon to Trac) would be gazilion times larger than it is now. The recent fight with memory leak in Genshi shows that, even if the core members of the two projects are almost the same, the administrative overhead is big. > Now imagine a Python where the core python team maintained all the standard > libraries and everything was built together in one big interpreter. Most of > the new libraries being added to the std lib are external packages that they > just snapshot when making releases (ctypes, pysqlite, etc). They are still > developed independently. > FYI: the ctypes project is in the same SVN repository and pysqlite is a part of the official Python tree :) Of course there is always a transition period when it is better to separate development of some new subsystem and the larger subsystem the larger this period. But this is not the point. The point is that such modules as glob, getopt, difflib etc. are in the stdlib! And their maintenance is much easier because of that - the common unit tests will catch any inconsistency. Another point is that in many cases the plugin's in question code size is ridiculously small but the functionality is a common place in other systems - take the WikiRename plugin for example. Maintaining it separately is a waste of time IMHO. Look at the trac-hacks - how many plugins are updated to 0.11? How many of these updated are updated/mantained by the core developers? Yet another point is that core developers are loaded by the plugins maintenance anyway. > I don't think things like ticket dependencies are such crucial features that > putting them behind a single checkbox is a bad idea. I would rather that > checkbox pull in a plugin than just enable built-in functionality, since it > will be transparent either way. > 1-click installer suggests that there always compatible plugin version is always available. You said it yourself in another message that 'putting them behind a single checkbox' is not an easy task. Forking PyPi would be the same scale project as the Trac itself. Also note that not all environments would allow software installation on a server through the WEB - this is a serious security problem. It would be interesting to gather somehow the information on what is the average number of plugins used in Trac installations. Regards, Mikhail --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
