On Thu, Jul 08, 2010 at 12:41:21AM +0200, Steffen Hoffmann wrote: > Don't let this be your last word on this topic.
With John kindly proposing his time, maybe it's not! Time will tell if me and him have enough common interest to do the world any good. I will contact you off-list in the coming weeks, John, thanks for your support. > That said I like your idea about bringing Trac's database to a (more) > relational structure. Even if I'm not remotely trained to do i/o related > programming with Python, I wouldn't mind lending a helping hand for testing. That's great news, thank you for offering :) > Let me add a strong BUT now, since the initial post was not that strong > about the foreseeable migration path. I wouldn't even think about any > new Trac version that I couldn't upgrade to as I did by now. And I guess > there is a considerable number of Trac application that do as I do: I think you would reconsider this if the competing branch was on the market, and a viable migration path was possible. That's not true for all users, granted, but again the key is to serve for the *majority* long-term (who are not here), and not the minority (who are by definition quite happy with what they have already). > 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). 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..). Envision the current Trac system as a house, database is the basement, front-end (webui) on the top (middleware between). 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. Every single stairway, window, duct, wirepath and reinforcement in the house have been put there, incrementally, throughout the products lifetime, partly because of the quicksand. 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. Now the key point, is to envision these systems as finished products, standing side by side. The furniture in the basement is the sum of data in an installation, the contents of sqlite. 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. 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. 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. Can anyone demonstrate prior art of a project that successfully acheived such a feat with an incremental approach? 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). 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 ;-) Terje -- 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.
