On Wed, Jan 03, 2001 at 11:05:20PM -0300, Nicolás Lichtmaier wrote:
> Another bad habit I've seen recently are entries that require the user to
> go to the BTS to know what have happened. eg:
> * Finally managed to fix this bug (closes:Bug#6).
That's not a recent innovation - there have b
>>"Nicolás" == Nicolás Lichtmaier <[EMAIL PROTECTED]> writes:
Ian> I don't think that using the changelog bug-closing mechanism is
Ian> appropriate for when a bug is closed with no change to the code.
>>
>> Would you care to explain this statement? If closing the bug
>> is indeed propoer,
> Ian> I don't think that using the changelog bug-closing mechanism is
> Ian> appropriate for when a bug is closed with no change to the code.
>
> Would you care to explain this statement? If closing the bug
> is indeed propoer, why shouldn't the changelog mechanism be used?
> Indeed, I
On Tue, Jan 02, 2001 at 05:10:12PM -0800, Joey Hess wrote:
> I think that using a delivery mechanism that is explicitly *talking to*
> someone, rather than making a comment in a file that is not part of a
> conversation, tends to result less often in terse and uninformative
> things like:
> * U
Chris Waters wrote:
> I'm not sure I agree with the much-more-friendly part. I'd rather see
> a descriptive changelog entry than a terse and uninformative separate
> email. Basically, I'd say friendliness has more to do with style than
> with delivery mechanism.
I think that using a delivery mec
On Wed, Jan 03, 2001 at 11:26:43AM +1100, Brian May wrote:
[re: changelog bug closers]
> I think it is harder on the bug submitter to find out why the bug was
> closed. First you have to wade through the changelog entries to find
> the one relevant to the bug you submitted,
That's something we sh
On Wed, Jan 03, 2001 at 10:19:02AM +1100, Brian May wrote:
> I thought the Changelog was used to record changes in the package.
Something has changed: the fact that the bug is not present has been
documented (in the changelog itself).
I don't insist on this interpretation, but it doesn't seem
un
> "Chris" == Chris Waters <[EMAIL PROTECTED]> writes:
Chris> I'm not sure I agree with the much-more-friendly part. I'd
Chris> rather see a descriptive changelog entry than a terse and
Chris> uninformative separate email. Basically, I'd say
Chris> friendliness has more to do
On Tue, Jan 02, 2001 at 01:23:15PM -0600, Adam Heath wrote:
> I disagree with an entry of "Bugs closes previously: CLoses: #n". It
> gives no indication of when, how, or why a bug was fixed.
Being unnecessarily terse, whether in a changelog entry or in an
email, is obviously a Bad Thing. I
> "Ben" == Ben Collins <[EMAIL PROTECTED]> writes:
Ben> Just to comment on this little bit, I think it is
Ben> appropriate, because then the package's changelog serves as
Ben> sort of a FAQ if the issue is ever brought up again (and the
Ben> bug has expired from the BTS). It al
On Tue, Jan 02, 2001 at 11:40:53AM -0800, Joey Hess wrote:
> Ben Collins wrote:
> > Let's drop this conversation to the affect that it is a one time deal to
> > take care of as many bugs as I possibly could in the shortest amount of
> > time. It's not like I or anyone else makes a practice of this.
Ben Collins wrote:
> Let's drop this conversation to the affect that it is a one time deal to
> take care of as many bugs as I possibly could in the shortest amount of
> time. It's not like I or anyone else makes a practice of this.
Actually I've been seeing a fair amount of it lately.
--
see sh
On Tue, Jan 02, 2001 at 01:23:15PM -0600, Adam Heath wrote:
> On Tue, 2 Jan 2001, Joey Hess wrote:
>
> > Bugs don't expire from the BTS.
> >
> > I dislike the practice myself. If my bug's being closed out of hand, a
> > personal email makes it feel a little less cold. (On the other hand if
> > my
On Tue, 2 Jan 2001, Joey Hess wrote:
> Bugs don't expire from the BTS.
>
> I dislike the practice myself. If my bug's being closed out of hand, a
> personal email makes it feel a little less cold. (On the other hand if
> my bug was fixed, I don't mind wading through the changelog to find
> that..
Ben Collins wrote:
> On Tue, Jan 02, 2001 at 11:18:04AM +, Ian Jackson wrote:
> >
> > I don't think that using the changelog bug-closing mechanism is
> > appropriate for when a bug is closed with no change to the code.
> > James (you're still [EMAIL PROTECTED]) and Ben, do you agree ?
> >
>
On Tue, Jan 02, 2001 at 11:18:04AM +, Ian Jackson wrote:
> >>From the debian/changelog entry for glibc 2.2-7:
> [...]
> This caused the BTS to send a message to me saying:
The BTS forwarded you most of that message, actually.
> [The bug] has been closed by one of the developers, namely
>
On Tue, 2 Jan 2001, Ben Collins wrote:
> On Tue, Jan 02, 2001 at 11:18:04AM +, Ian Jackson wrote:
> >
> > I don't think that using the changelog bug-closing mechanism is
> > appropriate for when a bug is closed with no change to the code.
> > James (you're still [EMAIL PROTECTED]) and Ben, do
On Tue, Jan 02, 2001 at 07:52:31AM -0500, Raul Miller wrote:
> > Ben: I think you should re-open this bug.
> >
> > Single Unix Specification says:
> > [http://www.opennc.org/onlinepubs/7908799/xsh/stdio.html]
> >
> > A handle which is a stream is considered to be closed when either
> >
>>"Ian" == Ian Jackson <[EMAIL PROTECTED]> writes:
Ian> I don't think that using the changelog bug-closing mechanism is
Ian> appropriate for when a bug is closed with no change to the code.
Would you care to explain this statement? If closing the bug
is indeed propoer, why shouldn't th
On Tue, Jan 02, 2001 at 07:52:31AM -0500, Raul Miller wrote:
> Ben: I think you should re-open this bug.
>
> Single Unix Specification says:
> [http://www.opennc.org/onlinepubs/7908799/xsh/stdio.html]
>
> A handle which is a stream is considered to be closed when either
> an fclose() or
On Tue, Jan 02, 2001 at 11:18:04AM +, Ian Jackson wrote:
>
> I don't think that using the changelog bug-closing mechanism is
> appropriate for when a bug is closed with no change to the code.
> James (you're still [EMAIL PROTECTED]) and Ben, do you agree ?
>
Just to comment on this little bi
> " " == Raul Miller <[EMAIL PROTECTED]> writes:
> For this be true, it must also be true that no data will be
> lost when a command line like the following is executed, and
> the file system is full:
> $ command blah blah... >file
> For example, the program could wa
Ben: I think you should re-open this bug.
Single Unix Specification says:
[http://www.opennc.org/onlinepubs/7908799/xsh/stdio.html]
A handle which is a stream is considered to be closed when either
an fclose() or freopen() is executed on it (the result of freopen()
is a new stream,
>From the debian/changelog entry for glibc 2.2-7:
* Checking printf returns is left to the programmer, closes: #28250
* Ok, the 51 pages of flaming in tis bug report leads me to believe that
this will never be resolved in glibc. IMO, it is up to the programmer
to be smart enough to
24 matches
Mail list logo
