Wow, Michael! That was fast. We're very happy campers over here now.
Thanks to you for taking this on and moving it so expeditiously and so
PS: The horizontal positioning would benefit braille displays and people
using software based magnification. The reason is that no braille
display (or magnified screen segment) can contain all the data displayed
by the 25 X 80 display. The effect is rather like looking at the screen
through a soda straw. One uses smart scrolling strategies to move the
straw around and get the information. Therefore, you want to park the
cursor where the most important information is.
That's the theory. I am only presuming that Mario Lang, the maintainer
of brltty and of accessibility for Debian, did the job right. I do trust
Michael K. Johnson writes:
From: "Michael K. Johnson" <johnsonm(a)redhat.com>
I think that there might have been some confusion; I moved the
conversation over to the development list to handle the
development side of the conversation, and this might not have
been obvious. I expressly wasn't really trying to deal with
this as a user-level issue, rather trying to bring out some
development points. So please forgive the development view
you'll see in this conversation; I didn't mean to imply that
only developers are welcome!
And see the end for some good news on this particular bug
On Tue, Aug 19, 2003 at 03:10:59PM -0400, Janina Sajka wrote:
> I certainly intend no disparagment of you, personally. I appreciate that
> you are the one who responded on this issue when others have not.
> Frankly, I also feel that I should not have had to get involved in this. But,
> here we are.
Thanks, and agreed. We're trying to make progress from where we are.
> > response and doing some initial analysis and pointing out a
> > potential question about the patch.
> If I missed the question, I apologize. Please forgive me and repeat it.
It's about the purpose of half the change in the patch; the change
to the horizontal positioning, whereas the bug report is about the
> I, too, want to help speed the resolution. For the eyes-free user, this
> bug is a showstopper--as the analogous situation would be in the visual
> interface if pressing enter on "English" brought up the Danish install
> screens visually, forexample, as they actually do with eyes-free.
I understand that. And, in fact, so do our QA staff, who regularly
run our installer in languages they do not know, and rely on their
knowledge of the installer to verify its operation in an unfamiliar
> I see two points that I want to respond to:
> 1.) The issue of process.
> 2.) The issue of this particular bug.
Thank you for separating them.
> Absolutely agree, but this also illustrates my problem with the extant
> Red Hat process--the much more important issue here. You see, there was
> never a problem with newt for eyes-free interfaces through Enigma (Red
> Hat 7.2) The problem appeared in Valhalla, and was reported before
> Psyche was released. Since then we've gone through Shrike and are now in
> Severn, a beta preceeding yet another release with no actioni on a
> showstopping issue for an entire class of users. Clearly,
> this principle of not breaking things has not served us at all in this
> instance though we have screamed "ouch." This is what I mean when I
> characterize the RH process as "unconsionable."
> more fundamentally, how does such a profound stumbling block for an
> entire class of users make it past QC at Red Hat? I appreciate your
> (and others) efforts to chase this process issue down inside Red Hat,
> for it surely will reoccur if it is not ameliorated.
One of the changes we have made recently to address this has been to
involve a developer more closely in the process. Before, non-developers
had assistive hardware and attempted to confirm, but were insufficiently
integrated into the process, and since they were not themselves visually
impaired, the degree of the problem was possibly not as obvious to them.
There are two problems here, both of which are addressed. Let me start
with the later: Because Red Hat is opening up the process, visually
impaired community members can find these problems quickly when they
occur; it will be more obvious to them than to the community of developers
and QA at Red Hat; we do not currently have any visually impaired developers
or QA staff and so it just isn't as obvious within Red Hat when something
breaks. For example, for someone who has a braille cheat sheet written
up on his whiteboard, problems with braille terminals are just not going
to be as obvious as for someone who depends on them daily.
The former problem has been addressed by moving the test hardware over
to a developer, thus integrating them earlier into the development
cycle and hopefully expediting fixes.
We won't be perfect, we will have bugs, but we made two general process
improvements that I hope will help. Time will, of course, tell.
> Of course, but how does that proceed? Who's to do it?
I just realized that I forgot to put my description of the question
into bugzilla as well as sending it to the list. I have just
In general (that's important) Red Hat gets more patches submitted
than we can fully analyze. Part of the process of submitting a
patch should be describing why the patch is correct, not just
confirming that it somehow addresses the bug being reported.
In this particular case, Red Hat can try to analyze it. However,
whowever created the patch should have already done the analysis,
so it is silly for us to re-do the analysis from scratch instead
of having the initial analysis provided with the patch.
So *anyone* has the option of doing the analysis, but the patch
author is the obvious person for the task.
> What are the known potential conflicts that need evaluation?
Unfortunately, wrong question. It's the unknowns that need to be
addressed through proper analysis of the change.
> And, when can we expect this to move to resolution?
I do not have an answer for that right now. By discussing the
potential for anyone with the ability to analyze code to participate
in the path toward the solution, I have attempted to speed up the
movement to resolution.
> And, if no one steps up to the discussion, as no
> one else has as of yet, does that mean the fix is in for the next
> release and we should expect it in the forthcoming beta? I expect it at
> least in the next release. It's just that much of a showstopper where I
> Surely you aren't waiting on us to prove a negative?
Proof of a negative, as I think Sayers remarked, is notoriously
hard to come by. Analysis, however, can demonstrate WHY the patch
is correct, and analysis that demonstrates that the patch is correct
is a necessary precursor to applying the patch. My mails here have
been trying to show how, especially with our new, more open process,
people who do not work for Red Hat can speed things along by
participating in the process.
Update: I just got an internal analysis from someone who knows newt
better than I do (msw), who says that from his analysis the patch is
"clearly correct", so I can change my tune. He explicitly reviewed
the horizontal as well as vertical positioning. So the fix will go
The point I've been trying to make (remember, I have no experience
in the newt source code) is that anyone could contribute this
"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
Rhl-devel-list mailing list
Janina Sajka, Director
Technology Research and Development
Governmental Relations Group
American Foundation for the Blind (AFB)
Email: janina(a)afb.net Phone: (202) 408-8175