From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2003-06-19 08:06:48
Gennaro Prota wrote:
> On Wed, 18 Jun 2003 10:01:58 -0500, Aleksey Gurtovoy
> <agurtovoy_at_[hidden]> wrote:
> > ... as per http://article.gmane.org/gmane.comp.lib.boost.devel/20648
> > are available from here:
> > * user summary page -
> > http://boost.sourceforge.net/regression-logs/user_summary_page.html
> > * developer summary page -
> > Please comment!
> Nice :-)
> I particularly like the fact that they are organized by
> library, rather than by platforms as were the latest regression logs I
> have seen.
Well, actually at the moment these are for a single platform only (win32).
Having the most recent results for each platform collected into a nice
single summary table is something that I hope somebody will address further
down the road.
> Personally I would like the green fail (in the developer summary) to
> read 'expected fail', for instance (or an abbreviation, such as 'exp.
> fail'). I'm the kind of guy that when faced with a 'fail' in a green
> cell begins wondering whether there was an error in the script :-)
Understand the sentiment; 'exp. fail' is not bad at all, IMO.
> Also, since 'doesn't work' and 'broken' (in the user summary) are
> practically synonyms, I would simply use a dash or an empty cell
> instead of the former.
Uhm, they are not, though! 'broken' on the user summary page indicates that
_the current_ CVS state is broken, probably to somebody's erroneous checkin,
but, as its legend says, that doesn't at all mean that the library is not
usable on that compiler. Basically it says "if you get me know, I won't
compile". As soon as the regression is fixed, all broken statuses will
become "OK" or "OK*". "doesn't work" means, well, doesn't work, permanently.
> But these are really minor points.
> More importantly instead, would it be possible to also have a sign
> indicating regressions? A little gif comes to mind, but even something
> as simple as an asterisk could be ok.
Hmm, I am not sure I understand what we are talking about here. Anyway,
ultimately, the developer summary page is supposed to serve as a regressions
indicator, but for it to work every library author need to go through the
trouble of specifying the expected failures and fixing everything else.
Thanks for the thoughts,
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk