[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

RE: fedora-startqa

On Fri, 2004-04-02 at 18:15, Erik LaBianca wrote:
> XML Output is a great idea IMO. We can define a schema for a review, and
> then use xslt to generate the actual review. We should all be able to
> easily agree on the xml schema, and for those that love to tweak they
> can always change the output template. 
> In all reality, there may be a certain amount of benefit to actually
> posting the review in XML. It's obviously the easiest way of making the
> reviews computer parseable.
If we get to the point of having tools within which you can write a
complete review, we could have the tools post an xml review as an
attachment and a human formatted review as the attachment's comments. 
(Although we then run into the problem of not everybody using the tools,
so the build architecture needs to understand this double posting as
opposed to a single posting method.)

(Hmmm... second thought, it may not be so bad.  The build architecture
can scan for gpg signed review in either attachments or comments.  Our
tools would only sign the XML review.  Then it can compare the reviews
by version and output.)

> This may already be what you're doing, I must apologize for not looking
> at your code yet :)
I've defined a DTD for describing a checklist (So people with different
ideas of what a QA Checklist report could theoretically contribute new
checklists.)  It needs some feedback and real-world stomping on. 
There's two things that I want to do to extend it but I'm not sure how
at the moment.

My save file format is going to reflect this checklist DTD somehow. 
It'll probably need to contain;
* checklist name (to link to the checklist)
* entry name (to link it back to the checklist item)
* display or hidden (So the information in the review is there, just not
* Resolution (Needs-Reviewing/Pass/Fail/Non-Blocker/Not-Applicable)
* potential output (The review information)

Since there is already potential output in the checklist, I'm not sure
what I'll limit it to. (one for every item?  One for every output item
that has edited review output?)  It'll be good to work with others on
defining these things.


  t  o  s  h  i  o  +  t  i  k  i  -  l  o  u  n  g  e  .  c  o  m
                                                          GA->ME 1999

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]