> If anyone has outstanding issues, please contact me, I want them gone.
Please, do not feal that I for my part reject your ideas, however, I do feal that much of that can already be achieved by implementing a plugin or multiple plugins thereof. In there you can define your own data model. In fact, you could also provide a new ticket system that would implement what you think would be best for the ticket system in trac. Since the original ticket system itself is merely a collection of extensions, each of them can easily be replaced. > If the list in general has issues with me, make sure this is communicated, > or I will assume it not to be the case. No issues with you, really. And I hope that no offense was taken on your behalf, if I sounded somewhat rude - like I said, I am also one who falls in the door, head first with lots of noise and then people will eventually come and stop me right at the entrance. > Quite possibly because I did not submit a detailed enough explanation > of the envisioned system from the start, but rather assuming that its > position in the core would be assessed by the readers given SQL code. Yeah, merely displaying things in just words is difficult, even in our native language we will find problems communicating things as clearly as possible without the help of additional media. > War was *NOT* my intention in starting the topic, it was love :-( :D War and Hate is was keeps going the machinery of man. As such, sometimes a little stirring and eventually a few rant tirades help a lot. > Sorry, but some of the posters were hostile towards me also, at least I > experienced it that way, even if it was not their intention. You must understand that you criticized their baby that they raised and nurtured - it is hard for developers to go unbiased about the achievements of one self, especially when the product as a whole finds wide attraction, and is even used by for example sourceforge to help maintain internal projects. And they surely know what an awkward codebase is, not to mention the datamodel. > The list, in general, I feel (sorry) did not really pick up the topic at > hand. And I *fully* admit my own out-of-line rambles being a large part > of that, apologies, hugs and <3 :* kisses offered by the dozen to anyone > who was offended. Sorry. The problem is, that most of what you brought up is already documented in the trac wiki. Multiple project support is a clear goal that has not been achieved yet, partly due to the data model, which is actually centered around a single project approach. Which does not mean, that you cannot do multiple projects with a single trac environment. In fact you can do it, but it requires a lot of discipline, like when you are setting up a new wikipedia from scratch, considering each term a project in itself, along with categorization and other things you definitely have to define a work flow and make up a plan on how to utilize the tools at hand. > And of course, here is another fatal error that I have made from the first > post onwards (maybe). I have not even *considered* the fact that growth > and wide adoption may not be the primary goal of the project, I > **BLINDLY** assumed it was. Having pointed this out already, trac is widely accepted and adopted by the community. Many teams use it for their everyday work, and even larger sites do use it for their own projects. >> And, again, about work effort. It is simply an attribute to a, what you >> would call work unit, or a ticket in trac terms. > > I don't think I understand how you perceive the model at all. > > I will reiterate a little bit on this, since it is in fact ON topic ;-) > > Have a quick look here: > > http://hansolav.net/sql/graphs.html#graphs > > WorkEfforts is the list of nodes (dbo.Node in link) > WorkEffortAssocs is the list of edges (dbo.Edge in link) > WorkEffortTypes declares available node types in the graph > WorkEffortAssocTypes declares available edge types in the graph Well, maybe we have different understandings of the term 'work effort'. In my understanding work means that something is to be done or is actively being done, something that also has a clear recipe of how it has to be done (best case). worst case would be that you have absolutely no clue on how that work is to be done but you start off working on it anyway. Now, in comes the effort. The effort is the time taken to actually get the work done. For one who knows the recipe, the effort remains low, but for one who is not so familiar with it, the effort increases with the unability of the worker. Thus, you have Work and WorkEffort, where WorkEffort is clearly an attribute or property of Work. That is the problem I have with your analysis. Perhaps, you might have a look into the OOPM project over at openoffice.org where such analysis / feature requests was done in part during the feature request phase of the project. You can find the information in the issue tracker associated with the project. > The latter two not used in linked examples, but it should be obvious > that they allow nodes and edges to be of different types across the graph. We do not argue that having a graph representation of something is wrong. But it actually might not apply to tickets. Of course, you are right, that individual tickets, if you call them dependent on each other, like for example as in Bugzilla where you can have tickets that either depend on or block another or multiple other tickets. That way, of course, you are building up directed, a-cyclic graphs. A similar, yet more reusable concept was already though of and can be found in the trac wiki on the trac dev proposal pages. It might even be found on the GenericTrac page, but I am not so sure of that. It was about introducing a table for inter-object associations, so that you can build up multiple such directed, a-cyclic graphs, for example inter-wiki page relationships, ticket parent/child relationships, dependent ticket relationships and so on. > Sorry if that was a waste of time, again. No, no waste of time is when we do not come to a fruitful discussion. Like I already said, you stomped into the house, everyone was awake but dozing away, and got startled by so much noise :D > I submitted what I (still) think is an excellent solution to a long- > standing core problem, wiping the *vast* majority of hard breakdown/ > management/estimation problems in a one-go at the storage layer (by > using a graph, for which all the cost/estimation/path algorithms *already* > exist, in case that was unclear??GOD!!!!! WHY did I not think to write > such things in the first post?????). Can you imagine what a Trac plugin > operating on such an underlying data structure could *DO*?!?! Of course, you are talking project management and cost evaluation and so on. Nice to have tools, but something that also can be added to the ticket system based on plugins and also custom fields. And, as you already know, such solutions already exist on trac-hacks. Or, if you really dare, you might provide you custom ticket system, build from either scratch or by extending the existing ticket system, and hook that into the system instead of the old one. But, and this is a big one, trac is not only about project management and cost evaluation and estimation. It is about fun getting things done, easily. So the core data model is agnostic to such idioms from more specific domains, like for example project management, and it captures only the most fundamental attributes and properties you also find in the more specific domains. -- Carsten PPS: a heavily patched trac is always a pain in the ***... especially when migrating to a newer version of trac. especially more so when the plugins from trac-hacks being used are long unmaintained. Initially, I just did that, but then gave up and began learning python and trying to learn about the plugin mechanism found in trac. Except for a few very special cases, I would never come back to patching trac now. -- 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.
