Hi Terje, >> stick with default SQLite database since the upgrade to next Trac >> version is guaranteed to work like a charm, so no need to become a real >> DB admin just to handle Trac. The automatic upgrade should be a >> must-have for any change and I urge you to not underestimate that point. > > I would not underestimate that point in a million years, but in order to > acheive this feat you must defy all sorts of universal laws. The core > issue > with the current codebase is a fatal design flaw, that has been present > for > a long time. Each and every single line of core and plugin code, is placed > exactly where it is, and written exactly as it is, partly to compensate > for that fact. The system is *HIGHLY* complex, and since there is no > actual > underlying data model, we *cannot* know what exists in the deployments in > the field (that we are upgrading from).
Besides that trac definitely needs an ORM (something of which Christian is strongly against), I do not think that the design is flawed. As to complexity, yes, but given a few day's hours, one can easily understand the request processing model inherent to trac. And, as far as my understanding goes, it is rather straight forward, compared to for example Java based JEE servers. And, besides that, database upgrades are actually handled very well. This, however, is only for the most generic case, e.g. trac using sqlite/mysql/postgresql. If you have an installation that uses a different dbms backend, or you have a highly patched version of trac, then it is up to you to either publish your patches so that the community can benefit, else you will have to redo your patches over and over again with every new trac release that requires changes to the data model. > Thus we have stumbled on one of the very, very few cases where a major > rewrite is historically favoured over an iterative approach (see wizard > post for philosophical details..). Major rewrite is out of question with the current main developer base, as there are only two and both of them have a RL. > These layers are *highly* interrelated, due to the fact that the ground > in the basement is quicksand and not solid, all sorts of reinforcements > have been built along the way, to compensate for the useless foundation. Hm, I do not think that the data model is that flawed, otherwise I would not have taken the track of adopting trac for my personal needs. Having reviewed many code based prior to sticking to one particular system has led me to trac, since its inherent architecture is easy to grasp and to extend upon. Except for the binding towards the data model not being based on an ORM of some sort, but this is only of low priority to me, as long as the data model does not feature any redundancies or is overly complex. And both is not the case with trac's datamodel. > When you model a new house, built on solid ground, you handle the vast > majority of such problems up-front to the actual building, so you don't > have to restructure the house several times during the development process > to keep it standing. This is not common in software architectures, as you know. Even Eclipse, with its plugin/extension point based architecture is subject to degeneration, unless the developers keep everything up to date, even more so the plugin developers. Software systems are always evolving and are never built on top of solid ground, to put up your phrase. The same holds true for data models and schemas deployed to a given dbms. As for trac's core component based, extensible architecture, it was even adopted by a different group lately. And, for my part, I must say that it is very well done, easy to understand once you get into python meta classes, and also very easy to extend upon. > In order to find a migration path, via code, between these systems, that > retain compatibility throughout the process, you will need several million > incremental commits (a huge patch-queue between houses, that *must* happen > in the *EXACTLY* right order for the system to work as a whole at each > transitional stage along the way). > > The old things that were invented because of the quicksand, have no direct > counterpart whatsoever in the new system, and thus an incremental move > between them is highly difficult. Ah now, I begin to understand your rambling more clearly. Afaik, this is already the case with trac, and if it is not it can be implemented very easily. Bitten also features or rather will feature such an atomic upgrade mechanism. For my own plugins, which have not been released yet, I have implemented a very similar mechanism that will update the data model and the schema deployed in the database and the data therein incrementally. And, hopefully, even on failure, it will be able to continue upgrading the system from where it last failed. Basically, this is just an attribute in the system table, which gets incrementally updated, for each upgrade available. If interest exists, I would be glad sharing this with the developers of trac a/o bitten, but since it is based on the original trac upgrade mechanism, it would be rather simple for you to also figure it out :D > Even if you had the finished new system to look at, you are still trying > to > move all the sand on a beach by picking up one microscopic grain at a time > instead of using power tools. Now you are talking in riddles. What power tools are you talking about? ORM? Ask Christian about ORM and his opinion on this. I for my part would definitely favour the move towards an ORM, be it SQLAlchemy or a self developed ORM hosted on edgewall.org. However, introducing an ORM means extra complexity for plugin developers. As of now, trac has been really easy to grasp by even newbies in python, so they could develop their own extensions, or adopt existing extensions for their purpose. > To show the point in a different way - the new system has full > multi-project > support. In an upgrade process from old to new, where does this > information > come from? It is several existing *environments* in the old system, that > will > be represented as several *projects* in the new. This is old talks. And many before you have talked about the subject and failed contributing working code. Given, the current system only supports a single project per IP, or multiple projects per IP which are all different instances of trac. So, perhaps, trac needs a new uberproject view/browser/community site solution that would integrate existing projects into a single uber project? Perhaps you ask osimons on #trac for more information on how to do it. For granted, they are using a heavily patched version of trac. And as far as my reckoning goes, this might be one reason for trac evolving so slow into a more multi project solution. > Can anyone demonstrate prior art of a project that successfully acheived > such > a feat with an incremental approach? sourceforge? > Rewrite is the only cost-effective way, in terms of reaching the stated > final goals of the project. If you are not doing the rewrite, you must > change the goals (or knowingly spend your time with very low ROI). Hey, we are talking about a community hosted and developed OSS project here, we do not talk finance nor ROI. It is all done in the people's spare time, since the original developer, the company once called edgewall, has gone. In case you missed that point, I'd like to make it clear to you. As for a complete rewrite, I would be in for this, if you can spare a hand or two joining the effort. > I dispute your case that this functionality is realistically present today > at > all. Please show 20 different lists, each containing a combo of 5 or more > plugins from trac-hacks or elsewhere, that will work as flawlessly as you > describe in a move from 0.11 to 0.12 in a production environment today ;-) As was previously stated, even for the major IDEs today, adopted by most companies in the world, namely either Eclipse or NetBeans, plugin developers must adopt to changes as soon as they come or they will become incompatible with the new release. This is the way software goes, even more so with integrated environments or platforms thereof. As a side note: What trac needs is active developers and of course developers that can be architects, or architects that are also active developers. Sort of, eat your own dog food - even providing working prototypes of your supposedly new architecture would help. Even UML diagrams or text based proposals of the new architecture would help in stirring a conversation on of moving towards the next gen trac architecture. I for my part could join your effort, having done research in this field for a couple of years now. Merely speaking in riddles and general rambling will not help, though. Of course, you are just like me. Before adopting an idea, I will rant on it, curse upon its deficiencies (not so with Windows though, as it is always a decificiency). But once I get into it, and especially more so if the code base is clean, I accept it. See also http://www.chinapage.com/gnl.html#01 for a more philosophical aspect on the flow of things and the way things are (Lao Tze, Tao Te Ching). -- Carsten -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to trac-...@googlegroups.com. To unsubscribe from this group, send email to trac-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
