On Mon, Aug 18, 2003 at 03:07:20PM -0400, Janina Sajka wrote: > May I please point out that I ask as a user, and as a disability > professional on behalf of thousands of existing users--to say nothing of > yet more users who won't give Red Hat the time of day right now because > of issues like this? 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 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. > So, let me question the issue at hand. Has the fix been tested? What is > the report? If there's a problem, wouldn't you agree we're entitled to know > about it? And, if there isn't a problem, shouldn't the fix be in? 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. 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. 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, michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/
