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 blindl
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, Mathie
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
--
* 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]
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 th
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 inform
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 dire
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 fin
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
> 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 san
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 t
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 s
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,
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 c
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 to
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 f
> 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, bu
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
> * 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 sympto
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: #
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
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 ins
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 change
> 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 conv
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
> > in
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 correc
> > * 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
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 summar
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 wo
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 plac
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, 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 h
> > "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 rais
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
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 change
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 submit
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é :
> > > "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
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 explana
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
> >> Architec
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 u
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
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
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 beli
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 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 re
> > 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
[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.
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 M
49 matches
Mail list logo
