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
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
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
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
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
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
* 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]
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
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:
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.
* 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
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
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
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
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
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
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
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
* 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
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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.
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
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
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
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
[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.
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
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
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
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
-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]
50 matches
Mail list logo
