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@xxxxxxxxxx > 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@xxxxxxx Phone: (202) 408-8175
