Bug 69903 newt -- Why no progress?

Janina Sajka janina at rednote.net
Wed Aug 20 14:06:12 UTC 2003


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
effectively. 

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
him, though.


Michael K. Johnson writes:
> From: "Michael K. Johnson" <johnsonm at 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
> report...
> 
> 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
> vertical positioning.
> 
> > 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
> language.
> 
> > 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
> rectified that.
> 
> 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
> > sit.
> ...
> > 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
> in.
> 
> The point I've been trying to make (remember, I have no experience
> in the newt source code) is that anyone could contribute this
> analysis.
> 
> michaelkjohnson
> 
>  "He that composes himself is wiser than he that composes a book."
>  Linux Application Development                     -- Ben Franklin
>  http://people.redhat.com/johnsonm/lad/
> 
> 
> --
> Rhl-devel-list mailing list
> Rhl-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/rhl-devel-list

-- 
	
				Janina Sajka, Director
				Technology Research and Development
				Governmental Relations Group
				American Foundation for the Blind (AFB)

Email: janina at afb.net		Phone: (202) 408-8175





More information about the devel mailing list