On January 27, Sean McBride started an e-mail conversation about the<br>state of VTK's dashboards. Although he initiated the conversion about<br>frustration over gerrit recurring test failures, the conversation<br>quickly moved to the state of VTK software quality.<br>
<br>The following is a highly edited 15 reply e-mail discussion:<br><br>SM: But with VTK, there's pretty much no build machine that's green,<br>    and so the "*Tests failing*" section seems to be almost always a list<br>
    of false positives (wrt to the patch at hand).Could this email be<br>    enhanced to divide the "*Tests failing*" section into 'newly failing'<br>    vs 'still failing'?<br><br>DC: We could write tests that pass.<br>
<br>SM: That'd be nice too, but, practically speaking, given the state of<br>       the VTK dashboard over the years, I thought my suggestion might be<br>       easier, and of course not mutually exclusive to yours<br>
<br>DC: Granted. But it sure would be nice to see it greened up once again<br><br>MH: It would be easier to make them green than try to devise some<br>       "baseline of failing tests".<br><br>BL: The quality of vtk code continues to decline... Our vtk community<br>
       has lost the will to keep the toolkit at the high quality levels vtk<br>       had in the past.<br>       We should all be embarrassed.<br><br>DG: Your statement that we test less than 1/2 of the code is false.<br>
       There are some dashboard machines (e.g. hythloth) cover much more.  I<br>       know that I'm being picky with semantics here, but the truth is, we<br>       have so many failing tests that the dashboard isn't even able to<br>
       produce accurate code quality metrics.<br><br>BL: I agree that there are so many failing tests that we have no idea<br>      about the quality of vtk. In the past, we bragged about our<br>      process. We cannot do that anymore.<br>
<br>DG: Now the overall issue of developer participation in the code<br>       quality process... that's a much bigger issue than the dashboard<br>       alone.  Is it a mentorship issue, i.e. are new developers not being<br>
       taught the "ways of the source"?  Are there too many developers,<br>       i.e. too many cats to herd?<br><br>DM: So yeah, lets discuss how to and improve our processes, and all<br>       chip in like the good team we are to clean up the dashboard. But no I<br>
       don't think that anyone should be ashamed of the state of things.<br>-------------------------------------------<br><br>"You can talk the talk, but can you walk the walk?"<br><br>On January 27,<br>Gerrit: 26 recurring failures<br>
Continuous: 12 recurring failures<br>Nightly Expected: 0 green, 21 red dashboards<br><br>Since January 27, the community started walking again.<br>On March 7,<br>Gerrit: 0 recurring failures<br>Continuous: 0 recurring failures<br>
Nightly Expected: 21 green, 7 red<br clear="all"><br>-- <br>Unpaid intern in BillsBasement at noware dot com<br>