This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
I volunteered to do this on the call today. Here's my thoughts on
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
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
[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.