On Tue, Jul 06, 2010 at 09:55:13PM +0200, Remy Blank wrote: > I'm a bit sad that this discussion turned so quickly into a shootout, > even though it started so well. > Sure, you change large portions of the existing code, but you do it > *incrementally*, in the open, and taking feedback from the existing > community into account. You may want to read the following article and > its references, which describes the situation quite well:
The shooting continues..? ;-) I fully agree that iterative is the best approach. My comment, that you replied to here, was from the perspective of a poor, newbie end-user attempting to add a "simple" local feature, and not regarding core development process *at all*. Sorry if that was unclear. Your link was an ok read. However, I think you must be misunderstanding me on several levels. The team has already planned the major changes, I am not directly proposing a rewrite or anything of the sorts. The question is what end-goal we should have for "1.0". Maybe that point has been watered down by all the sidetracking. The philosophy currently deployed, is: "We don't care if a large portion of the code reinvents the underlying database technology" I can live with that, it's deployed, it works just fine for a small team. Note that I didn't start this thread for the duration of one year on the list, even though I could have argued the exact same points much earlier. The planned future philosophy to replace it is: "We are going to defy all the known principles of relational systems, and use that as a foundation to reinvent them in the coming fourty years" This is a much more difficult to accept. So when a major milestone is reached, the topic to look into the future is raised. I fully agreed with Felix in that the data model needs attention. Christian did not seem to understand it, and I though I would submit my thoughts on the problem scope, and an illustration of what the industry-standard solution to the problem at hand is (the SQL). Hence I propose a relational approach: "We should use the relational capabilities we already *have* in the system to gain simplicity in middleware and a normalized data model" The key point: The viability of GenericTrac (or any variation/derivative thereof) as a data model, whether reached iterative or monolithic is *NOT PROVEN*. Still, you are committed. > - A big, monolithic rewrite gets a -1. I proposed to establish a research codebase to determine the viability of the future model, not to rewrite trunk immediately. My message is, again, to test the model before you commit to it. First, it makes sure you do not commit to something that will not work. Second, it establishes the boundaries of the model, so the future weak- spots can be identified and considered. Call me oldfashioned, but I just like to know that, when I am investing thousands of man-hours, I will land at a good solution and not one that needs refactoring or completely new optimization layers in core the following year. Maybe that is, as consensus seems to be here, not worth the time at all. The question is though, if an experiment showed the planned approach would *not* work for a medium-large team, would you reconsider? Or would you still commit thousands of man-hours according to plan? The problem with the planned approach, is that the model cannot scale. There is an absolute upper limit to the amount of data you can manage with this approach. Fundamentally, that means, Trac will be resricted in use case to either 1) small teams over a long period of time or 2) large teams over a short period of time. Each of these scenarios will inevitably lead to collapse of the system in a production environment, sooner or later (and thus not attract a wide audience, as a standard model would have). An experiment will show this to be true. I proposed to do it together with you to prove it, but nobody from the core team cares to join. I have done it before, though, so I really only proposed to break the news gently. The solution is to use the database to store data in a normalized way, as was intended by its designers. > - Infrastructure changes that don't bring a concrete advantage to > either the users, administrators or plugins developers get a -1. Agree, also, 100%. It's just that I think the previously proposed long- term solutions deserve the -1, and the proven relational approach deserves the +1, for the exact arguments you list. This is where we seem to not come together *AT ALL*, and hence is probably the central reason for all the guns and bombs ;-) > I doubt this. Just having a normalized database won't magically attract > flocks of new, motivated developers. I don't think it's by magic either. I simply think that a normalized data model has real-world usage potential far beyond all of our imaginations. And that, I think, will attract users. Motivated developers is another issue, but - at least - just the thought of having a system like Trac *with* a standard data model in the open, gets *me* excited;-) > You may be surprised to learn that people didn't wait for that change to > put Trac into production environments. As a starting point, see: I humbly apologize if you interpreted my statement as negative in terms of real-world usability of the current system. That was *not* my intention at all, as you know I am currently running it in production myself. It's the *range* of teams and processes it can be deployed in that will increase with a standard approach, in my opinion. > Although I wouldn't suggest forking as readily as Noah, I agree with him > that we have seen too much hand-waving and too little concrete > argumentation until now. I think the hand-waving may be largely due to the nature of the replies received, but I apologize anyway. Did you take some time to consider Work Effort model as a replacement for the Ticket/Milestone system and the role pattern at a fundamental level, and the practical implications it would have for the architecture, end-users, admins, plugin and core devs down the road? None of you have said a constructive word about it, one way or the other, yet still you claim I have not presented an argument. It's far from a complete argument, granted, and you may need experience with SQL to grasp it fully, but the argument is there. The relational approach is proven in millions, if not billions of applications. It is well documented. Trac data model can be built from proven, off-the-shelf parts, to handle exactly the kind of requirements that are present. There is only one major exception to this, and it is the custom field subsystem. However, excellent prior art exists for such solutions, even in the open. GenericTrac or any variation or derivation thereof, has yet to be defined, developed, or tested in any meaningful way whatsoever, yet it still is touted as the planned solution to what SQL has been solving in all industries since the 70s. It just sounds really backwards to me. Can anyone demonstrate prior art of a database-centric system that does not have an official stance on normalized data modelling, uses no relational features of the database, but still manages a high-load multi-user multi-project distributed system in production environments, across several supported relational backends? Can anyone demonstrate prior art of an in-memory assembly of key-value pairs to abstract a relational storage mechanism? I only intended to provoke serious consideration of the approach to data modelling, and I did it *only* because you guys asked for it, not because I was prepared to fork the codebase or create a new product from scrach to prove that relational systems really do serve a purpose. I thought it would be nice to offer my help on the specific issue along with the criticism too, but as Noah accurately predicted, "Trac-proper" is indeed not very interested unless it's incremental code. And so, I guess we leave it at that to save banddwidth on all layers. Thanks everyone for your time, I have gathered the information I was looking for. I am sad that noone spoke up in favour, and will now stop beating the topic further to death. Let me know if any modelling work is needed. At least I tried.. Terje -- 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.
