Bug 69903 newt -- Why no progress?

Janina Sajka janina at rednote.net
Tue Aug 19 19:10:59 UTC 2003


Michael K. Johnson writes:
> 
> 
> I'm actually not in charge of newt, but jumped in to work on this
> because I care about the issue; I'm the one who asked Red Hat to
> host blinux-list years ago...  So please cut me a little slack
> while I jump into something -- newt -- that I'm not normally involved
> in, source code that I've never read before.  The closest I've gotten
> to newt before is using the python interface (snack.py) years ago.

I certainly intend no disparagment of you, personally. I appreciate that
you are the one who responded on this issue when others have not.
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 I should not have to get involved in this. But,
here we are.
Frankly, I also feel that I should not have had to get involved in this. But,
here we are.

> 
> I gave an honest answer about what might have prevented the bug
> report from being expeditiously handled before.  I have also been
> chasing this down internally, in addition to posting that initial
> 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.
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 see two points that I want to respond to:

1.)	The issue of process.
2.)	The issue of this particular bug.

About the process ...
> The problem doesn't have to do with testing.  This is an excellent
> opportunity to discuss a subtlety of development.  Many times, a
> patch is provided which fixes the bug in question, and it is easy
> to determine that it fixes the bug in question, but it's still not
> a correct patch for one reason or another.  Often it is because it
> introduces other bugs in other places.  Fundamentally, patches
> require review not just for whether they fix the reported bug, but
> also for whether they are a correct modification.

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

And, I do mean the process, and not just this particular bug because
basic knowledge of accessibility would have prevented this problem from
ever cropping up in Valhalla. The technical accessibility issue is well
known. To put it in simple terms, the highlight bar says the focus is one place,while the console cursor says it's elsewhere.

more fundamentally, how does such a profound stumbling blockfor 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 isnot ameliorated.

o, to the specific bug at hand ...
> 
> The changes to this patch were not described, it was just provided
> with "this patch fixes this bug".  That's GREAT.  It's VERY useful
> information.  But it does not mean that it's necessarily the right
> patch, it does not mean that it doesn't create other bugs.  The
> analysis is a key part of the process.
> 
> The "problem" here is not a known bug; it's precisely an unknown.
> Speaking for myself as a developer, I can't vouch for the patch as
> a correct modification to newt even though I have zero doubt that
> it fixes the particular bug reported in 69903.

Of course, but how does that proceed? Who's to do it? What are the known
potential conflicts that need evaluation? And, when can we expect this
to move 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.

What, exactly, do you mean when you write "the changes to this patch
were not described?" What additional information or description is
needed? By who?

Surely you aren't waiting on us to prove a negative?


> r long silence on a showstopping issue is deafening. We had silence
> whilst the process was Red Hat's alone, and we've had silence since it
> was opened up to the community--until you came along. So, I hope that
> I'm helping explain, but if I'm explaining the wrong things--tell me.
> Because, this is a showstopper, and likely to be evaluated as such in
> a Sec. 508 procurment context, for example--far more so than the
> absence of a capable screen reader. 

Thank you for taking this on and moving it forward. Please let me know
how to help.
> I followed up with an honest expression of the remaining problem
> -- one of analysis -- so that other list members would have the
> opportunity to contribute analysis that could speed the handling
> of this bug report.
> 
> I'm not demanding that anyone else do the analysis.  I'm only
> making the opportunity to participate in the analysis available
> so that anyone -- inside our outside Red Hat -- with the desire
> to contribute to the analysis can speed the process.  That's how
> our new open process works.  What I did was exactly what anyone
> inside or outside of Red Hat who is not the package developer
> could do to speed resolution of a problem.
> 
> Please remember that rhl-devel-list is where we're trying to have
> the bulk of the development discussions for the distro.  This means
> that not every answer you see here will be complete.  You should
> expect many emails to be part of a process of discovery.  If the
> response to opening up our process is that everyone takes offense
> when partial answers are posted, it doesn't bode well for the
> move to open development.  To be quite clear, the mail I posted
> here is essentially the same email (the technical analysis part,
> that is) that I would have sent to our internal development list
> to speed progress toward resolving the problem, before this list
> existed.
> 
> Hope that helps,

And I would echo your sentiment. 
> 
> 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