<div dir="ltr"><div dir="ltr">Hey,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 8, 2019 at 6:33 PM Miklos Vajna <<a href="mailto:vmiklos@collabora.com">vmiklos@collabora.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
The current practice is: if 'make check' passes (which is more or less<br>
enforced by Jenkins) and the change looks good to a reviewer, the change<br>
goes in. And then releases are based on time, so it's really rare that<br>
there are "blocker" bugs which would delay a release.<br>
<br>
The ideal for any new kind of testing (including accessibility) is that<br>
it's integrated into 'make check', and whatever those tests cover are<br>
not OK to be broken anytime.<br>
<br>
If the proposed a11y tests are part of make check, then it's easy to<br>
promise that they won't be broken; otherwise it's just a best effort<br>
thing without any guarantees.<br>
<br>
At least that's how I understood what Markus wrote, and I agree with<br>
that.<br></blockquote><div><br></div><div>Exactly that. With the added comment about the reliability necessary or developers will start ignoring test failures or even worse disable failing tests.</div><div><br></div><div>Kind regards,</div><div>Markus</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Regards,<br>
<br>
Miklos<br>
</blockquote></div></div>