Re: Accepted kaffe 1:1.1.1-1 (i386 source)
Matt Zimmerman <[EMAIL PROTECTED]> wrote:
>
>> Well the credit should definitely be directed at the submitter. The
>> blame however is squarely at the feet of the maintainer.
>
> This is not at all the case. A large percentage of patches that I apply to
> my packages are done more or less blindly. Specifically, the message
> translations.
This might be OK for translations. But for anything else, if something
goes wrong, then it's the maintainer's fault since he is the one who
decided to let the patch in.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
Ross Burton <[EMAIL PROTECTED]> wrote: >> > "The bug has been fixed" is everything I would need to know. I don't >> > really care if it was a typo, a new library, a rebuild or some magic >> > incantation with black dribbling candles, the bug has been fixed. > > On Fri, 2003-08-29 at 17:46, Mathieu Roy wrote: >> This approach surely don't raise the level of Debian. >> Maybe *you* do not care of the details about the bug you reported. But >> a Debian developer is entitled, normally, to provide information >> according to what *users* can expect. > > On Fri, 2003-08-29 at 16:12, Nikolaus Rath wrote: >> I do. > > If you want to see every change which was made to the source, read the > upstream Changelog. If you want to see Debian packaging changes, read > the Debian Changelog. It's simple really. :) No. Ignoring the fact that not all packages have upstream changelogs, it can be still quite complicated to find the corresponding entry to your debian bug report in the upstream changelog. --Nikolaus
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
Martin Michlmayr wrote: > * Martin Schulze <[EMAIL PROTECTED]> [2003-08-31 10:24]: > > . Updated deprecation information on getipnodebyname(3) (closes > > Bug#183112, Bug#176709, Bug#157746, Bug#152780) > > You're missing a colon after "closes". Eeeks. fixed. Regards, Joey -- If you come from outside of Finland, you live in wrong country. -- motd of irc.funet.fi Please always Cc to me when replying to me on the lists.
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
* Martin Schulze <[EMAIL PROTECTED]> [2003-08-31 10:24]: > . Updated deprecation information on getipnodebyname(3) (closes > Bug#183112, Bug#176709, Bug#157746, Bug#152780) You're missing a colon after "closes". -- Martin Michlmayr [EMAIL PROTECTED]
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
Matt Zimmerman wrote: > > > If I report "segmentation fault in ls", I--as a user of ls, not a > > > developer--couldn't care less about why it was segfaulting or how the > > > bug was fixed; I only care that it's been fixed. If a developer wants > > > to spend their limited time researching how the bug was fixed and > > > summarizing it in a changelog, great, but it's certainly not something I'd > > > expect everyone to do. > > > > It's not about summarizing how the bug was fixed. It's about summarizing > > the > > bug *itself* in the changelog. > > I certainly prefer it if the changelog tells how the bug was fixed. This > documents the difference between: > > * New upstream release >- Removed the entire subsystem which contained this bug (Closes: #xxx) > > * New upstream release >- Made the "foo" option create its file with sane permissions (Closes: > #xxx) See manpages (1.58-1) unstable; urgency=low [..] * New upstream source (1.58) (closes: Bug#175564, Bug#175287) [..] . Updated deprecation information on getipnodebyname(3) (closes Bug#183112, Bug#176709, Bug#157746, Bug#152780) . Updated realpath(3) now warns that MAXPATHLEN may not exist (closes: Bug#152136) . Upstream added links for modfl(3) and modff(3) (partially fixes: Bug#17872) . Upstream added undocumented(2) (closes: Bug#149397) [..] I hope this reflects good packaging practice. Regards, Joey -- If you come from outside of Finland, you live in wrong country. -- motd of irc.funet.fi Please always Cc to me when replying to me on the lists.
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
On Sun, Aug 31, 2003 at 02:27:16PM +1000, Herbert Xu wrote: > Listing random upstream changes in debian/changelog just because they > happen to fix bugs in the Debian BTS makes no sense. It makes sense to me, and I do it whenever possible. It is valuable to include in the Debian changelog information about _how_ a Debian bug was fixed, not only the fact that it was fixed. -- - mdz
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
On Sun, Aug 31, 2003 at 02:23:46PM +1000, Herbert Xu wrote: > Matt Zimmerman <[EMAIL PROTECTED]> wrote: > > > > I list the submitter when they have provided a patch, so as to provide for > > attribution, and therefore credit or blame, as appropriate. > > Well the credit should definitely be directed at the submitter. The > blame however is squarely at the feet of the maintainer. This is not at all the case. A large percentage of patches that I apply to my packages are done more or less blindly. Specifically, the message translations. -- - mdz
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
Gunnar Wolf <[EMAIL PROTECTED]> wrote:
>
> Ok, you could not care much about why was it broken and how was it fixed
> - but then again, we have a lot of different users somehow different
> from you, and I don't think you would be bothered by receiving this
> extra information. Some users might find it even useful. Some fellow
> developers might be interested in knowing how did you do it.
For Debian changes, sure.
For upstream changes, definitely not. This is what the upstream changelog
and failing that, the upstream source is for.
Listing random upstream changes in debian/changelog just because they
happen to fix bugs in the Debian BTS makes no sense.
Cheers,
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
Matt Zimmerman <[EMAIL PROTECTED]> wrote:
>
> I list the submitter when they have provided a patch, so as to provide for
> attribution, and therefore credit or blame, as appropriate.
Well the credit should definitely be directed at the submitter. The
blame however is squarely at the feet of the maintainer.
Cheers,
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
> I certainly prefer it if the changelog tells how the bug was fixed. This > documents the difference between: > > * New upstream release >- Removed the entire subsystem which contained this bug (Closes: #xxx) > > * New upstream release >- Made the "foo" option create its file with sane permissions (Closes: > #xxx) I think there are two different kinds of bug-closing scenarios; and IMO, having the bug title and the submitter information would be benefitial, to get it edited to something useful. 1. A patch submitted through BTS which is directly applied : * Updated translation for ja.po From: Junichi Uekawa (closes: #) * Fix behavior of SIGSEGV handling From: Junichi Uekawa (closes: #) 2. A user report that did not contain a patch or anything that helped track down the problem, but at least the problem got fixed: * debian/rules: Removed unnecessary checks for environmental friendliness fixes "Package does not build from source on my dual-opteron machine" From: Junichi Uekawa (closes: #) * New upstream release implements "ACPI methods for controlling teapots" From: Junichi Uekawa (closes: #) For the second case, the maintainer needs to perform some manual editing to obtain a resonable changelog entry, as you suggest. Just a random thought. regards, junichi
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
Glenn Maynard dijo [Fri, Aug 29, 2003 at 04:03:16PM -0400]: > If I report "segmentation fault in ls", I--as a user of ls, not a > developer--couldn't care less about why it was segfaulting or how the > bug was fixed; I only care that it's been fixed. If a developer wants > to spend their limited time researching how the bug was fixed and > summarizing it in a changelog, great, but it's certainly not something I'd > expect everyone to do. > > (As a user, I'd certainly be rather annoyed at receiving duplicate close > reports because someone reopened the bug for frivelous reasons, however. > I get enough junk mail already.) Ok, you could not care much about why was it broken and how was it fixed - but then again, we have a lot of different users somehow different from you, and I don't think you would be bothered by receiving this extra information. Some users might find it even useful. Some fellow developers might be interested in knowing how did you do it. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
On Sat, Aug 30, 2003 at 11:06:20PM +0900, Junichi Uekawa wrote: > > One big problem with this approach is that the same maintainers who are > > too lazy to write proper entries for bug-closers in their changelog > > entries are going to be too lazy to ensure that a bug report has a > > meaningful summary in the first place. > > Maintainers who are lazy cannot be fixed, but some may improve, and > the load on those who do write proper changelogs may be lightened. > > I'd not expecting perfect results from here... just some improvements. > Less excuse for making sloppy changelogs :P Fair enough. Go for it, then! :) -- G. Branden Robinson| Debian GNU/Linux | If ignorance is bliss, [EMAIL PROTECTED] | is omniscience hell? http://people.debian.org/~branden/ | pgpWfmWh3DSws.pgp Description: PGP signature
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
On Sat, Aug 30, 2003 at 02:39:38PM -0400, Matt Zimmerman wrote: > On Sat, Aug 30, 2003 at 02:39:01PM -0400, Matt Zimmerman wrote: > > I list the submitter when they have provided a patch, so as to provide for > > attribution, and therefore credit or blame, as appropriate. > > And also, I suppose, if the submitter did a good job of tracking down the > bug and saved me time, and deserved credit for that. Yup. Both of those scenarios are exactly how I have been using my "thanks" messages in the XFree86 changelogs for years. -- G. Branden Robinson|Religion is regarded by the common Debian GNU/Linux |people as true, by the wise as [EMAIL PROTECTED] |false, and by the rulers as useful. http://people.debian.org/~branden/ |-- Lucius Annaeus Seneca pgpMvEDC1NHUp.pgp Description: PGP signature
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
On Sat, Aug 30, 2003 at 02:39:01PM -0400, Matt Zimmerman wrote: > On Sat, Aug 30, 2003 at 08:36:16AM +0200, Andreas Metzler wrote: > > > Peter S Galbraith <[EMAIL PROTECTED]> wrote: [...] > > > Right. I understood both points. I was wondering about having the bug > > > submitter there. Maybe change the phrasing? > > > > I usually don't list him/her, my changelogs are too long already. I do > > list submitters who send the report by private mail instead of via BTS, > > because othervise they wouldn't have any public record of their help. > > I list the submitter when they have provided a patch, so as to provide for > attribution, and therefore credit or blame, as appropriate. And also, I suppose, if the submitter did a good job of tracking down the bug and saved me time, and deserved credit for that. -- - mdz
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
On Sat, Aug 30, 2003 at 08:36:16AM +0200, Andreas Metzler wrote: > Peter S Galbraith <[EMAIL PROTECTED]> wrote: [...] > > Right. I understood both points. I was wondering about having the bug > > submitter there. Maybe change the phrasing? > > I usually don't list him/her, my changelogs are too long already. I do > list submitters who send the report by private mail instead of via BTS, > because othervise they wouldn't have any public record of their help. I list the submitter when they have provided a patch, so as to provide for attribution, and therefore credit or blame, as appropriate. -- - mdz
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
On Fri, Aug 29, 2003 at 04:34:58PM -0500, Adam Heath wrote: > On Fri, 29 Aug 2003, Glenn Maynard wrote: > > > If I report "segmentation fault in ls", I--as a user of ls, not a > > developer--couldn't care less about why it was segfaulting or how the > > bug was fixed; I only care that it's been fixed. If a developer wants > > to spend their limited time researching how the bug was fixed and > > summarizing it in a changelog, great, but it's certainly not something I'd > > expect everyone to do. > > It's not about summarizing how the bug was fixed. It's about summarizing the > bug *itself* in the changelog. I certainly prefer it if the changelog tells how the bug was fixed. This documents the difference between: * New upstream release - Removed the entire subsystem which contained this bug (Closes: #xxx) * New upstream release - Made the "foo" option create its file with sane permissions (Closes: #xxx) -- - mdz
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
> One big problem with this approach is that the same maintainers who are > too lazy to write proper entries for bug-closers in their changelog > entries are going to be too lazy to ensure that a bug report has a > meaningful summary in the first place. Maintainers who are lazy cannot be fixed, but some may improve, and the load on those who do write proper changelogs may be lightened. I'd not expecting perfect results from here... just some improvements. Less excuse for making sloppy changelogs :P regards, junichi
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
On Fri, 2003-08-29 at 20:17, Colin Watson wrote: > On Fri, Aug 29, 2003 at 08:48:13PM +0200, Mathieu Roy wrote: > > There's at least one other solution: what if, when a bug tagged > > "upstream" was closed, the mail sent would include the upstream > > ChangeLog (hopefully named ChangeLog in the top directory of the > > package)? > > Can someone familiar with the BTS code tell whether this change is > > trivial or not? > > It's not trivial in the slightest, sorry. The BTS doesn't remotely have > this information available to it, and it's not even easy to arrange for > it to be available. I'd also be quite annoyed if I was mailed the upstream changelog when a bug was closed, as these can often get rather large. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF signature.asc Description: This is a digitally signed message part
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
> * Bug fix "debian-changelog mode to support fetching of bug to fill >in changelog", Thanks to Junichi Uekawa <[EMAIL PROTECTED]> >(Closes: #207852). > > But I've always thought listing the thitle didn't really say _what_ was > fixed and _how_. Most times, the title mentions a symptom but not the > actual problem. That why I never added that before. Yes, that's one point, so the title usually needs editing. That's why it needs to be done at the level of debian-changelog-mode, and not dpkg. It's not something that can be completely automated, but at least some template is there to help the maintainer :) regards, junichi
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
On Saturday 30 August 2003 03:47, Branden Robinson wrote: > On Fri, Aug 29, 2003 at 06:00:51PM -0400, Glenn Maynard wrote: > > A script to convert eg. > > > > * New upstream release .* (Closes: #1, #2, #3) > > > > to > > > > * New upstream release \1 > > * fixed "BTS summary line of #1" Closes: #1 > > * fixed "BTS summary line of #2" Closes: #2 > > * fixed "BTS summary line of #3" Closes: #3 > > > > in changelogs would probably go a lot further to correcting this very > > minor issue than reopening dozens of bug reports that belong closed, > > annoying users with BTS garbage, and repeating the same thread on > > debian-devel over and over. > > One big problem with this approach is that the same maintainers who are > too lazy to write proper entries for bug-closers in their changelog > entries are going to be too lazy to ensure that a bug report has a > meaningful summary in the first place. maybe that should be a rule in policy. the issue of proper notification is valid, or not? there should be a means to at least reduce redundant bug reports, other than some nasty response indicating that a bug has already been reported or attended. us plain old users play a valid part in the project, but it's beginning to feel as though the gap between users and maintainers requires a whole new dialogue. it's not unreasonable to expect that user bug reports deserve a coherent response, including some degree of clarification of the means of bug resolution. ben
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
On Fri, 2003-08-29 at 18:12, Glenn Maynard wrote: > I'm confused. We have three cases: > > 1. Close bug #12345 directly (12345-done), noting the version that fixed it. > 2. Note in the changelog that bug #12345 is fixed; the bug receives a > notification of the version that fixed it. > 3. Note in the changelog that bug #12345, "ls --crash crashes", is > fixed; the bug receives a notification of the version that fixed it. > > #3 is obviously ideal, if the maintainer has time; no debate there. > > However, you're saying that #1 is preferable to #2. Why? It seems to > have no disadvantage to #1, with the added advantages that I can check > which version fixed bug #12345 without hitting the network (since it's > documented in the changelog), and saves developer time. What am I missing? Start with Herbert Xu's premise... > We've gone through this many times already. Upstream changes should > not be documented in the Debian changelog, even if they fix bugs in > the Debian BTS. ... and follow the bouncing ball. -- Joe Drew <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> My weblog doesn't detail my personal life: http://me.woot.net
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
Peter S Galbraith <[EMAIL PROTECTED]> wrote: [...] > Right. I understood both points. I was wondering about having the bug > submitter there. Maybe change the phrasing? I usually don't list him/her, my changelogs are too long already. I do list submitters who send the report by private mail instead of via BTS, because othervise they wouldn't have any public record of their help. > * Bug fix "debian-changelog mode to support fetching of bug to fill > in changelog", Thanks to Junichi Uekawa <[EMAIL PROTECTED]> > (Closes: #207852). > But I've always thought listing the thitle didn't really say _what_ was > fixed and _how_. Most times, the title mentions a symptom but not the > actual problem. That why I never added that before. The symptom often is much more interesting than the cause for the audience, i.e. "blah does not crash immediately on startup on PowerPC" instead of "Properly initialize char *foo in src/bar.c". cu andreas
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
On Thu, Aug 28, 2003 at 10:05:21AM -0500, Adam Heath wrote: > A proper entry is as follows: > > * New upstream release. > * no longer does foo when bar happens. Closes: #12345 > * wrapper script rewritten to not use $$ in tempfile names. Closes: #12345 > > Please, everyone remember, a changelog documents *changes*. It's not a tool > to close bugs automatically. Maybe a tool that integrates debian BTS/changelog behaviour could help. eg. You run program and give name of package. You see a list of bugs associated with the source packge. You select one of the bugs. It comes up with a screen with two windows: 1. One where the can review the bug history. 2. You type in extra information with what has changed, and an entry is automatically added to the changlog. You then repeat the process for the next bug report. This is still very rough, but I think it gives the general idea. Such a program could also make it easier to do common BTS tasks, eg. merge duplicate bug reports, etc. If we could make it easier and quicker to write correct changelogs, I think they are more likely to occur. (Assuming such a tool doesn't already exist...) -- Brian May <[EMAIL PROTECTED]>
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
> I'm not sure what the goal is? > Why do you want the bug submitter named in the Closes entry? > If its the title you want, then that is already available after the bug > list has been fetched. I've been wanting to use the title as initial > input to the close command for a wgile, but wasn't convinced it was good > enough. I guess it's a good first stab. That's what you guys want? Erm.. although having the submitter name is probably not the point, I wanted to point out to you that I want the bug subject, and the patch I have submitted you does that (and add the submitter name, for some kind of credibility). regards, junichi
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
Junichi Uekawa <[EMAIL PROTECTED]> wrote: > > I'm not sure what the goal is? > > Why do you want the bug submitter named in the Closes entry? > > If its the title you want, then that is already available after the bug > > list has been fetched. I've been wanting to use the title as initial > > input to the close command for a wgile, but wasn't convinced it was good > > enough. I guess it's a good first stab. That's what you guys want? > > Erm.. although having the submitter name is probably not the point, > I wanted to point out to you that I want the bug subject, Right. I understood both points. I was wondering about having the bug submitter there. Maybe change the phrasing? * Bug fix "debian-changelog mode to support fetching of bug to fill in changelog", Thanks to Junichi Uekawa <[EMAIL PROTECTED]> (Closes: #207852). But I've always thought listing the thitle didn't really say _what_ was fixed and _how_. Most times, the title mentions a symptom but not the actual problem. That why I never added that before. I could make it optional...
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
Junichi Uekawa <[EMAIL PROTECTED]> wrote: > > > * New upstream release \1 > > > * fixed "BTS summary line of #1" Closes: #1 > > > * fixed "BTS summary line of #2" Closes: #2 > > > * fixed "BTS summary line of #3" Closes: #3 > > > > > > in changelogs would probably go a lot further to correcting this > > > very minor issue than reopening dozens of bug reports that belong > > > closed, annoying users with BTS garbage, and repeating the same > > > thread on debian-devel over and over. > > > > Yes, that sounds pretty intesresting; an addition to debian-changelog-mode > > would be interesting. > > > > It should be possible to get bugs.debian.org/ and parse the resulting > > HTML for the title and the original submitter, and placing it. > > > > Some addition to debian-changelog-close-bug, possibly optional, > > that utilizes debian-bug-* (there's no debian-bug-to-buffer... hmm?) > > to parse the bugreport ? > > > Here is what the output looks like: > > ecasound2.2 (2.3.0-1) UNRELEASED; urgency=low > > * New upstream release > * Run autoconf-automae-libtool in build. > * jackd requires /proc/cpuinfo information not available on zaurus > From: Junichi Uekawa (closes: #207435) > > -- Junichi Uekawa <[EMAIL PROTECTED]> Sat, 30 Aug 2003 13:16:07 +0900 > > and here is the patch against debian-bug.el and debian-changelog-mode.el Thanks for CC'ing me. I catch up on -devel only sporadically. I'm not sure what the goal is? Why do you want the bug submitter named in the Closes entry? If its the title you want, then that is already available after the bug list has been fetched. I've been wanting to use the title as initial input to the close command for a wgile, but wasn't convinced it was good enough. I guess it's a good first stab. That's what you guys want? Peter
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
> > * New upstream release \1 > > * fixed "BTS summary line of #1" Closes: #1 > > * fixed "BTS summary line of #2" Closes: #2 > > * fixed "BTS summary line of #3" Closes: #3 > > > > in changelogs would probably go a lot further to correcting this very minor > > issue than reopening dozens of bug reports that belong closed, annoying > > users > > with BTS garbage, and repeating the same thread on debian-devel over and > > over. > > Yes, that sounds pretty intesresting; an addition to debian-changelog-mode > would be interesting. > > It should be possible to get bugs.debian.org/ and parse the resulting > HTML for the title and the original submitter, and placing it. > > Some addition to debian-changelog-close-bug, possibly optional, > that utilizes debian-bug-* (there's no debian-bug-to-buffer... hmm?) > to parse the bugreport ? Here is what the output looks like: ecasound2.2 (2.3.0-1) UNRELEASED; urgency=low * New upstream release * Run autoconf-automae-libtool in build. * jackd requires /proc/cpuinfo information not available on zaurus From: Junichi Uekawa (closes: #207435) -- Junichi Uekawa <[EMAIL PROTECTED]> Sat, 30 Aug 2003 13:16:07 +0900 and here is the patch against debian-bug.el and debian-changelog-mode.el diff -ur orig/debian-bug.el mods/debian-bug.el --- orig/debian-bug.el 2003-08-30 12:44:24.0 +0900 +++ mods/debian-bug.el 2003-08-30 13:22:59.0 +0900 @@ -1440,7 +1440,7 @@ (forward-sexp 1) (beginning-of-line)) -(defun debian-bug-wget-mbox (&optional bug-number) +(defun debian-bug-wget-mbox-or-html (download-mbox-p &optional bug-number) "Wget the mbox file for bug BUG-NUMBER and return the filename created." (if (not debian-bug-download-directory) (error "Please set ` debian-bug-download-directory'")) @@ -1456,11 +1456,17 @@ (concat "debian-bug-" (if debian-bug-package-name (concat debian-bug-package-name "-")) - bug-number) + bug-number +(if download-mbox-p +"" + ".html")) debian-bug-download-directory)) (status) (url (concat "http://bugs.debian.org/cgi-bin/bugreport.cgi?bug="; - bug-number "&mbox=yes"))) + bug-number + (if download-mbox-p + "&mbox=yes" +"" (if (and (file-exists-p filename) (not (y-or-n-p "Bug file already exists. Download again? "))) filename @@ -1472,6 +1478,14 @@ filename (error "`wget' failed")) +(defun debian-bug-wget-mbox (&optional bug-number) + "Wget the mbox file for bug BUG-NUMBER and return the filename created." + (debian-bug-wget-mbox-or-html t bug-number)) + +(defun debian-bug-wget-html (&optional bug-number) + "Wget the html file for bug BUG-NUMBER and return the filename created." + (debian-bug-wget-mbox-or-html nil bug-number)) + (defun debian-bug-get-bug-as-file (&optional bug-number) "Browse the BTS for BUG-NUMBER via `browse-url'." (interactive (list (completing-read "Bug number to fetch: " diff -ur orig/debian-changelog-mode.el mods/debian-changelog-mode.el --- orig/debian-changelog-mode.el 2003-08-30 12:44:18.0 +0900 +++ mods/debian-changelog-mode.el 2003-08-30 13:15:35.0 +0900 @@ -645,7 +645,22 @@ (if (not (string-match "^[0-9]+$" bug-number)) (error "The bug number should consists of only digits.")) (debian-changelog-add-entry) - (save-excursion (insert " (closes: #" bug-number ")")) + (save-excursion +(insert + (with-current-buffer +(find-file-noselect (debian-bug-wget-html bug-number)) + (beginning-of-buffer) + (concat + (progn + + (re-search-forward "\\([^-]*- #[^-]*- \\)\\([^<]*\\)") + (match-string 2)) + "\nFrom: " + (progn + (re-search-forward "From: \\([^&]*\\)") + (match-string 1)) + ))) +(insert " (closes: #" bug-number ")")) (message "Enter a brief description of what was done here.")) ;;
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
On Fri, Aug 29, 2003 at 06:00:51PM -0400, Glenn Maynard wrote: > A script to convert eg. > > * New upstream release .* (Closes: #1, #2, #3) > > to > > * New upstream release \1 > * fixed "BTS summary line of #1" Closes: #1 > * fixed "BTS summary line of #2" Closes: #2 > * fixed "BTS summary line of #3" Closes: #3 > > in changelogs would probably go a lot further to correcting this very minor > issue than reopening dozens of bug reports that belong closed, annoying users > with BTS garbage, and repeating the same thread on debian-devel over and over. One big problem with this approach is that the same maintainers who are too lazy to write proper entries for bug-closers in their changelog entries are going to be too lazy to ensure that a bug report has a meaningful summary in the first place. -- G. Branden Robinson|America is at that awkward stage. Debian GNU/Linux |It's too late to work within the [EMAIL PROTECTED] |system, but too early to shoot the http://people.debian.org/~branden/ |bastards. -- Claire Wolfe pgpaB7wR3YuAx.pgp Description: PGP signature
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
I'm cc'ing PSG, maybe he'll be interested. > * New upstream release .* (Closes: #1, #2, #3) > > to > > * New upstream release \1 > * fixed "BTS summary line of #1" Closes: #1 > * fixed "BTS summary line of #2" Closes: #2 > * fixed "BTS summary line of #3" Closes: #3 > > in changelogs would probably go a lot further to correcting this very minor > issue than reopening dozens of bug reports that belong closed, annoying users > with BTS garbage, and repeating the same thread on debian-devel over and over. Yes, that sounds pretty intesresting; an addition to debian-changelog-mode would be interesting. It should be possible to get bugs.debian.org/ and parse the resulting HTML for the title and the original submitter, and placing it. Some addition to debian-changelog-close-bug, possibly optional, that utilizes debian-bug-* (there's no debian-bug-to-buffer... hmm?) to parse the bugreport ? regards, junichi
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
On Fri, Aug 29, 2003 at 04:34:58PM -0500, Adam Heath wrote: > It's not about summarizing how the bug was fixed. It's about summarizing the > bug *itself* in the changelog. > > The description of the bug is already available(as the title of the bug > report). At the very least this should be placed in the debian changelog. How is this abusive? The maintainer is putting useful information in the changelog (the release a given bug was fixed), and closing the bug in the process. Not including a description of the bug seems no worse than not listing closed bugs in the changelog at all, and closing them all separately later on; I'm sure many maintainers without time to revisit lots of bugs after each upstream release do this. A script to convert eg. * New upstream release .* (Closes: #1, #2, #3) to * New upstream release \1 * fixed "BTS summary line of #1" Closes: #1 * fixed "BTS summary line of #2" Closes: #2 * fixed "BTS summary line of #3" Closes: #3 in changelogs would probably go a lot further to correcting this very minor issue than reopening dozens of bug reports that belong closed, annoying users with BTS garbage, and repeating the same thread on debian-devel over and over. -- Glenn Maynard
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
On Fri, Aug 29, 2003 at 09:31:29AM -0400, Joe Drew wrote: > Fine. Then don't close them with the Debian changelog at all; instead, > use [EMAIL PROTECTED], with an explanation that it is fixed in > such-and-such a version. The changelog bug closing facility is only a > convenience. I'm confused. We have three cases: 1. Close bug #12345 directly (12345-done), noting the version that fixed it. 2. Note in the changelog that bug #12345 is fixed; the bug receives a notification of the version that fixed it. 3. Note in the changelog that bug #12345, "ls --crash crashes", is fixed; the bug receives a notification of the version that fixed it. #3 is obviously ideal, if the maintainer has time; no debate there. However, you're saying that #1 is preferable to #2. Why? It seems to have no disadvantage to #1, with the added advantages that I can check which version fixed bug #12345 without hitting the network (since it's documented in the changelog), and saves developer time. What am I missing? -- Glenn Maynard
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
On Fri, 29 Aug 2003, Glenn Maynard wrote: > If I report "segmentation fault in ls", I--as a user of ls, not a > developer--couldn't care less about why it was segfaulting or how the > bug was fixed; I only care that it's been fixed. If a developer wants > to spend their limited time researching how the bug was fixed and > summarizing it in a changelog, great, but it's certainly not something I'd > expect everyone to do. It's not about summarizing how the bug was fixed. It's about summarizing the bug *itself* in the changelog. The description of the bug is already available(as the title of the bug report). At the very least this should be placed in the debian changelog.
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
> > "The bug has been fixed" is everything I would need to know. I don't > > really care if it was a typo, a new library, a rebuild or some magic > > incantation with black dribbling candles, the bug has been fixed. On Fri, 2003-08-29 at 17:46, Mathieu Roy wrote: > This approach surely don't raise the level of Debian. > Maybe *you* do not care of the details about the bug you reported. But > a Debian developer is entitled, normally, to provide information > according to what *users* can expect. On Fri, 2003-08-29 at 16:12, Nikolaus Rath wrote: > I do. If you want to see every change which was made to the source, read the upstream Changelog. If you want to see Debian packaging changes, read the Debian Changelog. It's simple really. :) Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
On Fri, Aug 29, 2003 at 08:48:13PM +0200, Mathieu Roy wrote: > There's at least one other solution: what if, when a bug tagged > "upstream" was closed, the mail sent would include the upstream > ChangeLog (hopefully named ChangeLog in the top directory of the > package)? > Can someone familiar with the BTS code tell whether this change is > trivial or not? It's not trivial in the slightest, sorry. The BTS doesn't remotely have this information available to it, and it's not even easy to arrange for it to be available. -- Colin Watson [EMAIL PROTECTED]
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
On Thu, Aug 28, 2003 at 10:05:21AM -0500, Adam Heath wrote: > A proper entry is as follows: > > * New upstream release. > * no longer does foo when bar happens. Closes: #12345 > * wrapper script rewritten to not use $$ in tempfile names. Closes: #12345 > > Please, everyone remember, a changelog documents *changes*. It's not a tool > to close bugs automatically. It documents which revision closed bug #12345. That's useful information for a changelog. It's certainly not worse than saying only "new upstream revision" and closing the bugs manually. > The BTS sends these close messages to the submitter when the bug is closed. > However, the email above has no reason as to why the bug was closed. It's not > sufficient to just say a new upstream version was uploaded, which just happens > to fix the bug. As a submitter, would you feel satisified that you had just > gotten such a mail? Absolutely! I reported a bug, and the mail says that the bug I reported has been fixed. That's all I need to know. If I report "segmentation fault in ls", I--as a user of ls, not a developer--couldn't care less about why it was segfaulting or how the bug was fixed; I only care that it's been fixed. If a developer wants to spend their limited time researching how the bug was fixed and summarizing it in a changelog, great, but it's certainly not something I'd expect everyone to do. (As a user, I'd certainly be rather annoyed at receiving duplicate close reports because someone reopened the bug for frivelous reasons, however. I get enough junk mail already.) -- Glenn Maynard
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
Ross Burton <[EMAIL PROTECTED]> a tapoté : > On Fri, 2003-08-29 at 14:18, Mathieu Roy wrote: > > > We've gone through this many times already. Upstream changes should > > > not be documented in the Debian changelog, even if they fix bugs in > > > the Debian BTS. > > > > Because users that submitted bugs using the Debian BTS do not deserve > > the right to get a mail meaningful about the bug they reported? > > "The bug has been fixed" is everything I would need to know. I don't > really care if it was a typo, a new library, a rebuild or some magic > incantation with black dribbling candles, the bug has been fixed. This approach surely don't raise the level of Debian. Maybe *you* do not care of the details about the bug you reported. But a Debian developer is entitled, normally, to provide information according to what *users* can expect. We are not here speaking about what some people do not care about but what some debian users do care about and how they can be easily satisfied. The fact that frequently we have to talk about that proves at least one thing: some users do care about details of the bugs and expect to get them in the changelog they receive by mails. If as debian developer you do care about what some *users* wants, the safest solution is to provide this information. It should takes you about 3 minutes to document these bugfixes. It is too much? Regards, -- Mathieu Roy Homepage: http://yeupou.coleumes.org Not a native english speaker: http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
On Thu, Aug 28, 2003 at 10:41:54PM +0100, Mark Brown wrote: > That doesn't help all that much - it's also important see why the bug > has been closed. Because it is fixed... > whatever it was I was trying to do when I generated the error rather > than by fixing the error handling. it wont help you, if it says "print a helpful error message". If you realy care that much, look up the patch. Gruss Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
Ross Burton <[EMAIL PROTECTED]> a tapoté : > > > "The bug has been fixed" is everything I would need to know. I don't > > > really care if it was a typo, a new library, a rebuild or some magic > > > incantation with black dribbling candles, the bug has been fixed. > > On Fri, 2003-08-29 at 17:46, Mathieu Roy wrote: > > This approach surely don't raise the level of Debian. > > Maybe *you* do not care of the details about the bug you reported. But > > a Debian developer is entitled, normally, to provide information > > according to what *users* can expect. > > On Fri, 2003-08-29 at 16:12, Nikolaus Rath wrote: > > I do. > > If you want to see every change which was made to the source, read the > upstream Changelog. If you want to see Debian packaging changes, read > the Debian Changelog. It's simple really. :) The debian changelog have the wonderful advantage to be sent by mail when a bug is closed. This person do not want to see "every change which was made to the source" neither do her want to see "Debian packaging changes" but want to see the change about the submitted bug. To get that information in the mail sent, the only solution would be to have it included in the debian changelog. There's at least one other solution: what if, when a bug tagged "upstream" was closed, the mail sent would include the upstream ChangeLog (hopefully named ChangeLog in the top directory of the package)? Can someone familiar with the BTS code tell whether this change is trivial or not? -- Mathieu Roy Homepage: http://yeupou.coleumes.org Not a native english speaker: http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
Herbert Xu wrote: This is bullshit. We've gone through this many times already. Upstream changes should not be documented in the Debian changelog, even if they fix bugs in the Debian BTS. Fine. Then don't close them with the Debian changelog at all; instead, use [EMAIL PROTECTED], with an explanation that it is fixed in such-and-such a version. The changelog bug closing facility is only a convenience.
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
Herbert Xu <[EMAIL PROTECTED]> a tapoté : > Adam Heath <[EMAIL PROTECTED]> wrote: > > > > On Wed, 27 Aug 2003, Ean R. Schuessler wrote: > > > >> -BEGIN PGP SIGNED MESSAGE- > >> > >> Format: 1.7 > >> Date: Wed, 27 Aug 2003 17:18:37 -0500 > >> Source: kaffe > >> Binary: kaffe > >> Architecture: source i386 > >> Version: 1:1.1.1-1 > >> Distribution: unstable > >> Urgency: low > >> Maintainer: Ean R. Schuessler <[EMAIL PROTECTED]> > >> Changed-By: Ean R. Schuessler <[EMAIL PROTECTED]> > >> Description: > >> kaffe - A JVM to run Java bytecode > >> Closes: 51230 61264 75800 77869 81389 116802 141597 158743 167936 170021 > >> 170059 193263 196254 196867 197617 200434 202779 > >> Changes: > >> kaffe (1:1.1.1-1) unstable; urgency=low > >> . > >>* New upstream release closes many bugs. (Closes: #51230, #61264, > >> #75800, #77869, #116802, #141597, #158743, #170021, #170059, > >> #193263, #196254, #197617, #202779, #81389, #200434, #196867) > >>* /usr/lib/jni is now checked for JNI libraries. (Closes: #167936) > > > > This is not a proper changelog entry. > > > > A proper entry is as follows: > > > > * New upstream release. > > * no longer does foo when bar happens. Closes: #12345 > > * wrapper script rewritten to not use $$ in tempfile names. Closes: #12345 > > > > Please, everyone remember, a changelog documents *changes*. It's not a tool > > to close bugs automatically. > > This is bullshit. > > We've gone through this many times already. Upstream changes should > not be documented in the Debian changelog, even if they fix bugs in > the Debian BTS. Because users that submitted bugs using the Debian BTS do not deserve the right to get a mail meaningful about the bug they reported? -- Mathieu Roy Homepage: http://yeupou.coleumes.org Not a native english speaker: http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
Ross Burton <[EMAIL PROTECTED]> wrote: > On Fri, 2003-08-29 at 14:18, Mathieu Roy wrote: >> > We've gone through this many times already. Upstream changes should >> > not be documented in the Debian changelog, even if they fix bugs in >> > the Debian BTS. >> >> Because users that submitted bugs using the Debian BTS do not deserve >> the right to get a mail meaningful about the bug they reported? > > "The bug has been fixed" is everything I would need to know. I don't > really care if it was a typo, a new library, a rebuild or some magic > incantation with black dribbling candles, I do. --Nikolaus
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
Adam Heath <[EMAIL PROTECTED]> wrote:
>
> On Wed, 27 Aug 2003, Ean R. Schuessler wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>>
>> Format: 1.7
>> Date: Wed, 27 Aug 2003 17:18:37 -0500
>> Source: kaffe
>> Binary: kaffe
>> Architecture: source i386
>> Version: 1:1.1.1-1
>> Distribution: unstable
>> Urgency: low
>> Maintainer: Ean R. Schuessler <[EMAIL PROTECTED]>
>> Changed-By: Ean R. Schuessler <[EMAIL PROTECTED]>
>> Description:
>> kaffe - A JVM to run Java bytecode
>> Closes: 51230 61264 75800 77869 81389 116802 141597 158743 167936 170021
>> 170059 193263 196254 196867 197617 200434 202779
>> Changes:
>> kaffe (1:1.1.1-1) unstable; urgency=low
>> .
>>* New upstream release closes many bugs. (Closes: #51230, #61264,
>> #75800, #77869, #116802, #141597, #158743, #170021, #170059,
>> #193263, #196254, #197617, #202779, #81389, #200434, #196867)
>>* /usr/lib/jni is now checked for JNI libraries. (Closes: #167936)
>
> This is not a proper changelog entry.
>
> A proper entry is as follows:
>
> * New upstream release.
> * no longer does foo when bar happens. Closes: #12345
> * wrapper script rewritten to not use $$ in tempfile names. Closes: #12345
>
> Please, everyone remember, a changelog documents *changes*. It's not a tool
> to close bugs automatically.
This is bullshit.
We've gone through this many times already. Upstream changes should
not be documented in the Debian changelog, even if they fix bugs in
the Debian BTS.
If I were the maintainer of this package, I would close these bugs again.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
On Fri, 2003-08-29 at 14:18, Mathieu Roy wrote: > > We've gone through this many times already. Upstream changes should > > not be documented in the Debian changelog, even if they fix bugs in > > the Debian BTS. > > Because users that submitted bugs using the Debian BTS do not deserve > the right to get a mail meaningful about the bug they reported? "The bug has been fixed" is everything I would need to know. I don't really care if it was a typo, a new library, a rebuild or some magic incantation with black dribbling candles, the bug has been fixed. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
On Fri, Aug 29, 2003 at 12:24:37AM +0200, Bernd Eckenfels wrote: > On Thu, Aug 28, 2003 at 10:41:54PM +0100, Mark Brown wrote: > > That doesn't help all that much - it's also important see why the bug > > has been closed. > Because it is fixed... The trick is working out why the maintainer believes the bug to be fixed. > > whatever it was I was trying to do when I generated the error rather > > than by fixing the error handling. > it wont help you, if it says "print a helpful error message". If you realy Which is rather easily distinguishable from "Support $STRANGE_REQUEST" and that's the kind of difference I'm talking about. It's also a bit confusing if the bug has been closed in an unexpected fashion - for example, by supporting a feature with a slightly different syntax to that expected. Bug reports aren't always models of clarity and sometimes maintainers don't always immediately grasp the issues being discussed. A few words of explanation can avoid a lot of head scratching and confusion. The more informative and helpful the changelog the less chance the easier it is to resolve any confusion that arises. > care that much, look up the patch. "New upstream release, diff only 1.2M!". -- "You grabbed my hand and we fell into it, like a daydream - or a fever."
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
Adam Heath <[EMAIL PROTECTED]> wrote: [...] >>* New upstream release closes many bugs. (Closes: #51230, #61264, >> #75800, #77869, #116802, #141597, #158743, #170021, #170059, >> #193263, #196254, #197617, #202779, #81389, #200434, #196867) >>* /usr/lib/jni is now checked for JNI libraries. (Closes: #167936) > This is not a proper changelog entry. [...] > The BTS sends these close messages to the submitter when the bug is closed. > However, the email above has no reason as to why the bug was closed. It's not > sufficient to just say a new upstream version was uploaded, which just happens > to fix the bug. As a submitter, would you feel satisified that you had just > gotten such a mail? Probably yes because the mail would start with This is an automatic notification regarding your Bug report #xxx "with this helpful subject" has been closed. OTOH anybody else reading the changelog will be disatisfied. cu andreas
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
On Thu, Aug 28, 2003 at 07:37:05PM +0200, Andreas Metzler wrote: > Adam Heath <[EMAIL PROTECTED]> wrote: > > to fix the bug. As a submitter, would you feel satisified that you had just > > gotten such a mail? > Probably yes because the mail would start with > This is an automatic notification regarding your Bug report #xxx > "with this helpful subject" has been closed. That doesn't help all that much - it's also important see why the bug has been closed. One of the common misunderstandings I've seen is bugs about poor error handling and diagnostics being closed by supporting whatever it was I was trying to do when I generated the error rather than by fixing the error handling. -- "You grabbed my hand and we fell into it, like a daydream - or a fever."
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
> > As a submitter, would you feel satisified that you had just gotten > > such a mail? > Yes, I would. I would then know that I could fetch the new release to > see if the problem was really fixed in this release. I must agree with Adam, and IIRC, there has alreadu been said on that list that it is an improper use of the changelog. As a bug sumbitter, I don't want to review source code each time I want to know if a bug is actually corrected. Simply because for some packages, I'm just unable to understand their code (being because of the language used or the complexity...). And the changelog should be something readable by a human being. making it clearer can only be a Good Thing. Explicitly, le Moine Fou -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A pgpBPVY8zsxs0.pgp Description: PGP signature
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
[Adam Heath] > As a submitter, would you feel satisified that you had just gotten > such a mail? Yes, I would. I would then know that I could fetch the new release to see if the problem was really fixed in this release.
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
reopen 51230 reopen 61264 reopen 75800 reopen 77869 reopen 116802 reopen 141597 reopen 158743 reopen 170021 reopen 170059 reopen 193263 reopen 196254 reopen 197617 reopen 202779 reopen 81389 reopen 200434 reopen 196867 thanks On Wed, 27 Aug 2003, Ean R. Schuessler wrote: > -BEGIN PGP SIGNED MESSAGE- > > Format: 1.7 > Date: Wed, 27 Aug 2003 17:18:37 -0500 > Source: kaffe > Binary: kaffe > Architecture: source i386 > Version: 1:1.1.1-1 > Distribution: unstable > Urgency: low > Maintainer: Ean R. Schuessler <[EMAIL PROTECTED]> > Changed-By: Ean R. Schuessler <[EMAIL PROTECTED]> > Description: > kaffe - A JVM to run Java bytecode > Closes: 51230 61264 75800 77869 81389 116802 141597 158743 167936 170021 > 170059 193263 196254 196867 197617 200434 202779 > Changes: > kaffe (1:1.1.1-1) unstable; urgency=low > . >* New upstream release closes many bugs. (Closes: #51230, #61264, > #75800, #77869, #116802, #141597, #158743, #170021, #170059, > #193263, #196254, #197617, #202779, #81389, #200434, #196867) >* /usr/lib/jni is now checked for JNI libraries. (Closes: #167936) This is not a proper changelog entry. A proper entry is as follows: * New upstream release. * no longer does foo when bar happens. Closes: #12345 * wrapper script rewritten to not use $$ in tempfile names. Closes: #12345 Please, everyone remember, a changelog documents *changes*. It's not a tool to close bugs automatically. The BTS sends these close messages to the submitter when the bug is closed. However, the email above has no reason as to why the bug was closed. It's not sufficient to just say a new upstream version was uploaded, which just happens to fix the bug. As a submitter, would you feel satisified that you had just gotten such a mail?
