[Piglit] Update some docstrings v2

[Daniel Vetter]

On Sat, Mar 15, 2014 at 07:39:45PM -0700, Dylan Baker wrote:
> On Saturday, March 15, 2014 08:41:15 AM Ilia Mirkin wrote:
> > On Sat, Mar 15, 2014 at 8:29 AM, Daniel Vetter <daniel at ffwll.ch> 
> wrote:
> > > On Fri, Mar 14, 2014 at 07:41:04PM -0700, Dylan Baker wrote:
> > >> [snip]
> > >> 
> > >> > > I'll throw a patch at the end of the series, do you want me to 
> send
> > >> 
> > >> I'm gonna take it back, sorry. I don't know that dmesg-warn 
> should be
> > >> worse than warn, (same for fail) since pass -> dmesg-warn, warn 
> ->
> > >> dmesg-fail, and fail -> dmesg-fail. Personally I was never a fan of
> > >> having
> > >> special dmesg- statuses, I feel that a fail is a fail and warn is a 
> warn,
> > >> but I'm not sure that change is correct.
> > > 
> > > The current ordering seems wrong to me, e.g. if you have a failing 
> tests
> > > and fix up some dmesg noise you now have a regression.
> > 
> > And if you add dmesg noise, you have a fix :) printk(), here I come!
> > 
> > On a mildly note, am I the only one who thinks it's weird that
> > transitions to/from (skip, notrun) are considered fixes/regressions?
> > 
> >   -ilia
> 
> I agree, that was changed be someone from my original 
> implementation, but obviously it was changed so at least one person 
> feels the current behavior is correct.

As mentioned such transitions make sense for the kernel where we never
break abi or disable old features (well, until the last user/hw
disappeared at least). Hence a fail->skip is a regression (probably the
kernel broke a feature flag) and fail->notrun is a regression (probably
the testcase is broken and dropped a subtest somehow).

fail->notrun has a bit a downside when doing a massive testcase renaming
for better consistency, but thus far we've only had one case where we've
done a bit of large-scale renaming in the last two years.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch