Re: Implementing accessibility non-regression check tool

[Jan-Marek Glogowski <glogow@xxxxxxxxxx>]

Am August 28, 2018 4:04:37 PM UTC schrieb Samuel Thibault <sthibault@xxxxxxxx>:
>Samuel Thibault, le lun. 12 févr. 2018 15:30:59 +0100, a ecrit:
>> - At some point we'll get confident that we won't introduce other
>> big classes of warnings over hundreds of .ui files. That's the point
>> where we can say "ok, let's start fixing the existing issues over
>> all .ui files once for good". We can then run through .ui files one
>> by one, fixing the issues and removing the corresponding suppression
>> lines. These could be used as "easy hacks" entries, they are usually
>> just a few lines to fix.

I'm not sure we want this handled as "easy hacks". The goal was to enable the checks always for the build. Is this implemented and can I enable it?

My preferred solution would be, that generating the error files in the current build wouldn't break it, but spill the errors to the console to annoy people, to get this fixed in time. Mind I have no ideas about the amount of output / the current state.

If everything is fixed, we can change it to actually break the build. This is a different category then translating German comments!

We can talk about this tomorrow on ESC, if the ML is not sufficient.

> I have completed documentation on fixing them on
>https://wiki.documentfoundation.org/Development/Accessibility
>
>Could people check this documentation before we advertise it more broadly as an "easy hack"?
Nice.

>> The progression of all of this could be monitored with statistics reported e.g. in the minutes of ESC calls.
So who would be responsible to fix it? If we don't test it on patch submission and break on error, it would just pile up again.

ATB

Jan-Marek
_______________________________________________
LibreOffice mailing list
LibreOffice@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/libreoffice