[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20170319144133.ep2em6uebaew4iwa@var.youpi.perso.aquilenet.fr>
Date: Sun, 19 Mar 2017 15:41:33 +0100
From: Samuel Thibault <samuel.thibault@...-lyon.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Petr Mladek <pmladek@...e.com>,
Aleksey Makarov <aleksey.makarov@...aro.org>,
linux-serial@...r.kernel.org, Joe Perches <joe@...ches.com>,
linux-kernel@...r.kernel.org
Subject: Re: Does braille console work?
Hello,
Steven Rostedt, on ven. 17 mars 2017 09:02:08 -0400, wrote:
> Samuel Thibault <samuel.thibault@...-lyon.org> wrote:
> > Petr Mladek, on ven. 17 mars 2017 10:35:44 +0100, wrote:
> > > Anyway, the feature is not usable at the moment. Samuel, would
> > > you be able to fix and test it, please?
> >
> > Sure, it's already on my TODO list, I will do when I get the time.
>
> Yes please.
Done so.
> There's no reason to keep that code if it's been broken for
> 3 years and nobody noticed.
It's rather that nobody complained. That's what usually happens with
accessibility: when something breaks, the concerned users do notice, but
end up just thinking "ok, yet another regression..."
> In fact, keeping it may actually make it
> more difficult to add accessibility in the future. Methodologies may
> change and the old broken code (that we've been complicating all other
> code with), may actually become a hindrance to a new methodology.
Why so? I would say the contrary: the existing code shows the actual
needs and how they can be implemented. That's the usual "show me actual
code" question answered.
> Getting rid of the complications it adds to the core code, and let the
> core code become more simplified may actually end up being easier to
> add accessibility in the future, than keeping the old cruft around.
No, because it means it'll get hard to get something implemented again,
because actual implementation will have been dropped.
Samuel
Powered by blists - more mailing lists