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(a)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(a)afb.net Phone: (202) 408-8175