With regards to a Gmail-style interface for labeling, got a comment/concern on the SQL.
IIRC, when cherry-picking was implemented (for performance reports), we attempted to compose a WHERE clause that would effect the cherry-pick. This led to some wild WHERE clauses. E.g., consider the following example: +---+----+----+----+---+ |# |A |B |C |D | +---+----+----+----+---+ |1 |1 |2 |3 |4 | |2 |5 |6 |7 |8 | |3 |9 |10 |11 |12 | |4 |28 |10 |11 |12 | |5 |29 |10 |11 |12 | +---+----+----+----+---+ If we want to cherry-pick lines 1, 2 and 3, then our WHERE clause will look like this: SELECT blah blah FROM blah,blah WHERE (A=1 AND B=2 AND C=3 AND D=4) OR (A=5 AND B=6 AND C=7 AND D=8) OR (A=9 AND B=10 AND C=11 AND D=12) We eventually chose do the filtering in PHP on row # since there does not seem to be a good way to filter by row # in SQL. The point being, a nasty WHERE clause *could* lead to a loooong tag operation. Given the above, a good starting point might be to restrict tagging to the following: 1. Allow tagging only on entire reports 2. Allow tagging only on a single row at a time My $0.02. -Ethan On Fri, Aug/24/2007 03:07:54PM, Jeff Squyres wrote: > I volunteered to do this on the call today. Here's my thoughts on > tagging: > > 1. From the client, it would be nice to be able to specify a comma- > delimited list of tags at any phase. Tags would be inherited by > successive phases if not explicitly overridden. E.g., if you specify > a "foo" tag in an MPI get, it'll be used in all phases that use that > MPI get. > > Tags can be specified in one of three forms: > > +foo: means to *add* this tag to the existing/inherited set > -foo: means to *remove* this tag from the existing/inherited set > foo: if any tag does not have a +/- prefix, then the inherited set > is cleared, effectively making the current set of tags be only the > non-prefixed tags and +tags > > For example: > > [MPI Get: AAA] > # + and - have little meaning for MPI Get > tags = foo, bar, baz > > [Test Get: BBB] > # + and - have little meaning for Test Get > tags = yar, fweezle, bozzle > > [Test Build: CCC] > # Test build inherits tags from MPI Get and Test Get > tags = +fa-schizzle, -yar > # Resulting tag set: foo, bar, baz, fweezle, bozzle, fa-schizzle > > [Test build: DDD] > # Override everything > tags = yowza, gurple > # Resulting tag set: yowza, gurple > > 2. For the reporter, I think we only want authenticated users to be > able to create / manipulate tags. Authentication can be via SVN > username / password or the HTTPS submit username / password; I don't > have strong preferences. > > Anyone can query on tags, of course. > > 3. We should have easy "add these results to a tag" and "remove these > results from a tag" operations, similar to GMail/labels. I think the > rule should be that if you can show MPI details (i.e., not the > summary page), you can add/remove tags. Perhaps something as simple > as a text box with two buttons: Add tag, Remove tag. > > 3a. Example: you drill down to a set of test runs. You type in "jeff > results" in the text box and click the "add tag" button. This adds > the tag "jeff results" to all the result rows that are checked (it is > not an error if the "jeff results" tag already exists on some/all of > the result rows). > > 3b. Example: you drill down to a set of test runs. You type in "jeff > results" in the text box and click on the "remove tag" button. This > removes the tag "jeff results" from all the result rows that are > checked (it is not an error if the jeff results" tag is not on some/ > all of the result rows). > > 4. Per Gmail index label listing, it would be nice to see a list of > tags that exist on a given result row. It could be as simple as > adding another show/hide column for the tags on a given result row. > But it gets a little more complicated because one row many represent > many different results -- do we show the union of tags for all the > rollup rows? Maybe we can use different colors / attributes to > represent "this tag exists on *some* of the results in this row" vs. > "this tag exists on *all* of the results in this row"...? > > 4a. If the tags are listed as a column, they should also (of course) > be clickable so that if you click on them, you get the entire set of > results associated with that tag. > > 4b. For every tag on a rollup row, it would be good to be able to say > "apply this tag to every result in this rollup row" (i.e., this tag > had previously only applied to *some* of the results in this rollup > row). This could be displayed as a little "+" icon next to the tag > name, or somesuch. > > 4c. Similarly, for every tag, it would be good to have a "remove this > tag from every result in this row". This could be displayed as a > little "-" icon next to the tag name, or somesuch. > > 4d. Care would need to be taken to ensure that users would not > accidentally click on "+" or "-" icons next to tag names, however. > > 5. There should also be a simple way to: > - see all available tags (perhaps including some kind of > indication of how many results that tag represents) > - completely delete a tag from the entire database > > 6. Tags may span multiple phases (install, build, run). If you click > on a tag that contains results on all three phases, what should > happen? I think it should be context-sensitive: > - If you are in a summary environment, you get a summary table > showing all relevant results. > - If you are in a single phase environment, you see only the > results in that phase (perhaps with a clickable icon to see the > entire summary table with all the tag's results). > > 7. Lots of things can, by default, become tags. E.g., org name and > platform name can become default tags. I.e., results that are > submitted will automatically have the org name and platform name > added to the results as tags. > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mtt-devel mailing list > mtt-de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
