nickson@comp.vuw.ac.nz (Ray Nickson) (08/11/89)
Some suggestions, that you might consider for a future release: - how about automatically-mailed bug reports always go to MAINTAINER, and only to you as a last resort? They could then include an `if you don't understand this, pass it on to me' type comment.... - how about automatically giving version numbers an extra field to say which number local build this is (a la emacs). i.e. my first build of 1.02 would be 1.02.1, etc. - would it be possible for you to comment on posted bugfixes when you've had a look at them, so people using bash as their login shell can keep up to date with fixes without incorporating unsanctioned fixes, which you have already indicated is a source of some annoyance to you (I've stopped posting patches for this reason). i know it means extra work for you, but it might be worth considering if it means people are testing a bash that looks more like your current version. - could bash move away from the #ifdef SYSV approach, towards something like emacs's config.h, where I have a separate symbol for each feature? (#ifdef SYSV_STRINGS, #ifdef HAVE_ALLOCA etc). This would be especially appreciated for HPUX, which is a SYSV system that becomes more and more BSD with each release. -rgn -- Ray Nickson, Dept. Comp. Sci., Victoria University of Wellington, New Zealand. nickson@comp.vuw.ac.nz ...!uunet!vuwcomp!nickson + 64 4 721000x8593
bfox@AUREL.CALTECH.EDU (Brian Fox) (08/11/89)
Date: Fri, 11 Aug 89 10:20:50 +1200
From: Ray Nickson <nickson@comp.vuw.ac.nz>
Some suggestions, that you might consider for a future release:
- how about automatically-mailed bug reports always go to MAINTAINER,
and only to you as a last resort? They could then include an `if
you don't understand this, pass it on to me' type comment....
What is the reason for this? If bug reports are mailed to me then I
have a chance of fixing them. If I cannot fix them because I need more
information, I can ask the local maintainer for more information, and
send them a copy of the bug report.
If the local maintainer gets the report, they may:
o Throw it away. This is not helping anyone to fix bugs.
o Fix the bug, and not tell me. This is good for them, but bad
for Bash in general
o Find and fix a bug which I have already fixed. This is a
waste of time for them.
o Find and fix a bug which I have not found and fixed, and then
mail me the fix. This is the most useful, but the hardest to
achieve.
Since I get multiple bug reports from different sites, I have more
examples which help to determine the cause of a bug.
- how about automatically giving version numbers an extra field to
say which number local build this is (a la emacs). i.e. my first
build of 1.02 would be 1.02.1, etc.
Okay.
- would it be possible for you to comment on posted bugfixes when
you've had a look at them, so people using bash as their login
shell can keep up to date with fixes without incorporating
unsanctioned fixes, which you have already indicated is a source
of some annoyance to you (I've stopped posting patches for this
reason). i know it means extra work for you, but it might be worth
considering if it means people are testing a bash that looks more
like your current version.
If the bash that someone is using is not one that I have, then I cannot
debug problems, nor post a fix.
- could bash move away from the #ifdef SYSV approach, towards
something like emacs's config.h, where I have a separate symbol for
each feature? (#ifdef SYSV_STRINGS, #ifdef HAVE_ALLOCA etc).
This would be especially appreciated for HPUX, which is a SYSV
system that becomes more and more BSD with each release.
As I add new features, I will keep this in mind. In general, I have
kept this in mind. I try to use SYSV for those sections of code which
are correct for a large set of System V machines. This is better than
having the separate machine names as defines.
brian