On Aug 25, 2008, at 4:36 AM, Noah Kantrowitz wrote: > Okay, so the reason this doesn't work is as follows:
Hi Noah, I think we're talking across one another, not actually to one another. None of the things you describe being problems in the MasterTicketsPlugin are things I am at all interested in doing for "subtickets" as I described them in my original post[0]. In other words, I specifically *don't* want an explicit (or even implicit) bi- directional relationship between two tickets to be enforced by the software. This "subticket/superticket" relationship is purely conventional (or theoretical) which is what makes it useful for me in the first place. Invariably, I find "blocking" and "blocked by" fields to be a burden rather than something helpful, something that project managers can use to micro-manage my time (…speaking only somewhat bitterly from experience). > The 0.10 version of mastertickets worked exactly as you describe, it > used a field (a custom field but it could have just as well been the > keywords) that contained the blocking/parent side of the dependency > data, and then created the other side on the fly by using some SQL to > extract data from the field (SELECT .... WHERE field LIKE "#n %" OR > field LIKE "% #n" OR field LIKE "% #n %" etc). There are a number of > problems with this approach. One, it is slower and increases DB load a > good bit. I imagine that using any of the macros that hit the DB enough would increase its load substantially. Certainly, the TracQueryMacro is one of these. Is this assumption incorrect, or is there something special about the ticket system that I'm not aware of? > Two, because the "blocked by"/child field doesn't actually > exist and is generated at render time, it can't be used like a normal > Trac field. It can't be changed directly (you have to click through > and > change it on the other side), it can't be searched, it doesn't record > changes, etc etc. Basically the entire Trac system has no support for > that kind of virtual field. That makes a lot of sense, and again is why I don't actually want such a field at all. When I enter a subticket keyword on a ticket to flag it as a "subticket" of another ticket, all I'm doing is saying "this ticket probably relates in some significant way to the work described by this other ticket." I'm not specifically saying it's a child ticket, or a dependency, or a blocking ticket, or any of these concrete things. You are certainly correct that in order to change a superticket's description to, say, remove the presence of a subticket generated from a TicketQuery macro listing one would have to click through to the subticket and remove the keyword from that ticket. However, this is true of any TicketQuery macro listing any other keyword as well. That behavior is actually what we want because the consistency of this interaction paradigm increases the software's usability. I think it would in fact be more difficult to understand a "blocking/blocked by" custom field that did support some kind of virtual bi-directional sync, since that introduces an entirely new behavior to the system that exists no where else. > Three, because there is no easy source of > raw dependency data in a relational format, making thing like a > depgraph > or blocker check were much harder. That's certainly a valid concern, if what I am after were dependencies or blocker checks. Fortunately, I am specifically trying to avoid just such a graph, because I strongly dislike such graphs as I find them to be, as I said earlier, "unhelpful because they *create* exactly the kinds of situations (blocks) we want to avoid." Put another way, I don't want to use software that makes it easier for me to give myself reasons why I am not doing any work. I like Trac so much because it does absolutely none of that in a vanilla installation. For what it's worth, from your reaction, I'm starting to think "subtickets" or "supertickets" is probably a bad name for what I'm doing since it evokes too much similar imagery to the whole dependency thing. Perhaps "somewhat related tickets" would be better, but it doesn't quite roll off the tongue as nicely. Anyway, all of your points make a lot of sense, and I appreciate that you took the time to describe the MasterTicketsPlugin to me. > You are welcome to keep going and I am sure you will discover all of > these issues. > > --Noah > > PS: I still think contains-word is a good addition to the query > system, > I just wouldn't use it to build subtickets. To each their own I suppose; and the fact that this is even possible is yet another reason why Trac is awesome in my book. Cheers, -- -Meitar Moscovitz Personal: http://maymay.net Professional: http://MeitarMoscovitz.com EXTERNAL REFERENCES: [0] http://marc.info/?l=trac&m=121936459010029&w=2 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Users" 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-users?hl=en -~----------~----~----~----~------~----~------~--~---
