Mr. Meitar Moscovitz wrote: > 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.
I think you mean to be saying "related tickets". In any case, not having the bi-directional linking seems silly to me, since you can only trace what is related in a single direction (not really up or down, since this more of a set of buckets than a tree). I think what you want is actually a graph (though a mostly flat one consisting of several clusters), but you are getting hung up on the concept of "blocking" which is orthogonal from creating a graph of ticket relations. The semantics of those relations are an entirely different topic. --Noah
signature.asc
Description: OpenPGP digital signature
