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/
