Emily Ammundsen wrote:
> I wished to test to see if
> the bug I wished to report still existed in the development version, as it
> was my impression that this was the polite thing to do (in order to avoid
> false positives, and for example, what I believe GCC wants bug reporters
> to do)
I would say, it's extra-polite: it's more effort than we at GNU expect
from a bug reporter.
We expect from a bug reporter only that they state the version they are
using; it does not need to be the newest release. If a bug report is well
done (with "How to reproduce" instructions) it will be easy for the package's
developers to reproduce it with the current release or with the newest
source code from git.
It is not your duty to check whether a bug is fixed in the newest
source code, not for Autoconf and certainly not for GCC. Building
GCC from source code takes 4-8 hours of CPU time if you have the
right recipe for doing that, and it probably takes 3-4 attempts
until you got a working recipe.
So, what you attempted is extra-polite, and it is risky to do because:
* We make releases with tarballs that are known to work.
* While some packages have continuous integrations that guarantee that
the newest source code mostly works, that is not the case for all
packages. Some GNU package maintainers work in the "traditional" way
where the newest source code has some issues that will only be fixed
shortly before the next release. If you, as a non-expert regarding
this package, build from git and encounter these issues, it will
be frustrating for you and — if you report them — annoying for the
maintainer who already knows about the issues.
> and that doesn't seem to fall into any of your three use cases.
From what I understand, you are in the second of the listed cases:
- If user wants things to work out-of-the-box => Fetch release tarball.
- If user is not an expert with the package and not willing to become
an expert with the package => Fetch release tarball.
- If user wants to hack things like a developer => Fetch a git clone,
read the HACKING file, and don't complain if things don't work as
expected.
> I downloaded the git version of autoconf and tried to build it (running
> into errors around shallow git clones) ...
> Though I suppose improving the documentation of HACKING is a potential
> solution.
Regarding the specific problem in Autoconf, I think any of the following
actions would be reasonable:
a) Ignore the issue, because use of 'git clone --depth 1' is not what
many people do.
b) Fix the problem by changing the bootstrap script: After the line
VERSION=$(build-aux/git-version-gen .tarball-version)
add
if test "$VERSION" = UNKNOWN; then
VERSION=`some command to extract the version from the NEWS file`
fi
c) Document in the HACKING file that a shallow git checkout won't work.
Bruno
