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
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
Hope that helps,
"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin