[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposed module, releasedate
From: |
James Youngman |
Subject: |
Re: Proposed module, releasedate |
Date: |
Thu, 10 Jan 2008 12:54:03 +0000 |
On Jan 10, 2008 1:06 AM, Bruno Haible <address@hidden> wrote:
> James Youngman wrote:
> > Lots of packages get bug reports for releases that are pretty old.
> > /* emit the standard version information first. */
> >
> > if (release_age (&age))
> > {
> > double weeks = age / (86400.0 * 7);
> > printf(_("This release is %.0f weeks old."),
> > weeks);
> > if (weeks > 26.0)
> > {
> > printf(_(" If you are considering reporting a bug,\n"
> > "please upgrade to the most recent release first.\n"));
> > }
>
> You are assuming that you will be able to make a release at least
> every 6 months?
Yes. But that code is in the example, not the module.
> If not, you will be asking users to look for a newer
> release, and then none exists - they will be frustrated for having wasted
> their time.
>
> Also, remember that most users use a distribution: Ubuntu, Debian, OpenSUSE,
> Fedora, whatever. From the moment you make a release, to the moment your
> release is picked up by the distribution, to the moment the distribution
> is released, often more than 6 months have passed.
Don't forget that the code you are commenting about is not itself part
of the module.
> So most of your users
> will have this warning already from the first day they get a new release.
Yes. Many people reporting bugs in packages would indeed find that
the bug is fixed in the upstream release. If a is bug present in the
distribution's packaged release but has been fixed upstream, the bug
should be reported to the distribution, not the upstream.
> Last not least, when someone wants to report a bug, there are more things
> he should take care of. I particularly encourage people to post complete
> version information and complete samples. This should best be documented
> in the manual - see e.g. the "Reporting Bugs" node in the GCC documentation.
> This doc certainly won't fit into the few lines of --version or --help
> output.
This is true. This is a proposed gnulib module, it should be no
surprise that it is not a substitute for adequate package
documentation.
> And finally, the GNU standards say that the email address that should be
> used for reporting bugs is part of the --help output; so it is unrelated
> to the --version output.
The module itself of course has no bearing on the GNU standards
compliance of a package that uses it, though.
James.
- Proposed module, releasedate, James Youngman, 2008/01/09
- Re: Proposed module, releasedate, Bruno Haible, 2008/01/09
- Re: Proposed module, releasedate,
James Youngman <=
- human-time? (was: Re: Proposed module, releasedate), Simon Josefsson, 2008/01/10
- Re: human-time?, Bruno Haible, 2008/01/10
- Re: human-time?, Simon Josefsson, 2008/01/10
- Re: human-time?, Simon Josefsson, 2008/01/10
- Re: human-time?, Bruno Haible, 2008/01/10
- Re: human-time?, Paul Eggert, 2008/01/10
- Re: 'make' modification time warning (was: Re: human-time?), Bruno Haible, 2008/01/10
- Re: 'make' modification time warning, Paul Eggert, 2008/01/11
- Re: 'make' modification time warning, Matthew Woehlke, 2008/01/22
- Re: Proposed module, releasedate, Bruno Haible, 2008/01/10