On Thu, Feb 5, 2015 at 9:08 PM, Daniel Manrique <[email protected]> wrote: > On Thu, Feb 5, 2015 at 1:42 PM, Zygmunt Krynicki
> <[email protected]> wrote: >> Hey. >> >> To refresh our usage of the mailing list I'd like to share the status >> of where we are with the meta-data story. The point of the story is to >> know the certification status of each job so that we can put it into >> reports. > > Awesome, thanks for working on this! Later down the line we need to > think how to model this on our server-side tools/database. I'll change checkbox-support to understand the new attribute and just expose it. I already wrote code for hexer to use that but I haven't tested or touched it in months really (it's the same code I wrote in Taipei). I think the general idea is that we want to put this on the test model (not the result model) and that's about it. >> The specification on how that should look like from the outside has >> been merged to trunk earlier today. You can read it here [1]. >> (side-story, we should build all CEPs into nice documents along with >> the rest of our documentation). The parts you may find especially >> interesting are all the examples that show how this looks like inside >> test plans and job units. > > The examples are very clear and pretty cool. Will both syntaxes be > supported? At first glance I like: The "APPLY value TO attribute" syntax has been supported for a good while now (for category overrides). The new additions are to make that syntax available to other attributes and to have the new syntax for compact representation (the other example). > > apply blocker to job-1 > > since it's very natural-languagey, however, that screams "parser" and > a) we know parsers are painful, and b) a problem with natural language > is that people tend to not treat them very seriously, "ah, it's > natural language so it'll understand anything I throw at it" and we'll > start seeing "set job-1 to blocker" or other things. Strict validation > will be crucial here to help developers grok the new syntaxes. This is parsed pretty strictly with down to this line and that column mistake details. I think it's okay. It's SQL-like and people generally have adopted that style of syntax without problems. > The compact syntax is more strict in that respect which may be better > or worse. The bottom line is that there's no silver bullet when we > introduce new syntax and trying to validate and hand-hold developers > will be important. Both are useful depending on what you want to do. I suspect we'll see more of the inline kind for now but we'll see. >> - I've made some changes to the exporter base and to the xml and html >> classes so that we have this data and can surface it. I've just pushed >> that code here [3]. I haven't actually tried using it much so feedback >> is appreciated. I haven't spent any time on making the actual HTML >> report look nice. I'm sure it's possible but given how friendly >> (*cough*) XSLT is it'd rather do something else. Oh, tests pass as the >> canned xml/html reports now differ. I didn't bother updating them >> until we have an acceptable looking report. > > How's progress on decoupling HTML from XML/XSLT? I guess this will > lessen the pain of doing what you describe, and I thought we'd decided > not to touch the XSLT and focus on the decoupling/templated native > HTML report instead. Sylvain was working on the actual reporter and from what I saw it was interesting but it's on hold now. I was working on a cleanup / re-factoring of how exporters are detected / accessed and that was practically done in the common case *except* in the case where you have missing dependencies on stuff like xml or that python-excel library. That complicates things and effectively undoes what I've changed. I'll push that branch if anyone wants to look at it. Eventually I'd like to see exporters as units. The code they execute needs to be provided centrally (jinja can handle everything except for office formats so I suspect two "engines" will be available) but actual template and any customizations can move to providers. Thanks ZK -- Mailing list: https://launchpad.net/~checkbox-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~checkbox-dev More help : https://help.launchpad.net/ListHelp
