Re: Proper way of closing *old* bugs
Adam, Here is what I meant, clearly: I took over the gnuplot package last week but I've only fixed 2 bugs out of 40. It's a shame because I'm supposed to handle them all when taking over the package and I did not. I'll do that as soon as possible but in the meanwhile, I've uploaded that package to put update the maintainer field and fix the easiest bugs. Depending on the situation, I'll handle the bugs that way : - if the bug is not reproducible anymore with the current Debian version, I'll close it directly with the BTS - if the bug is still reproducible, I'll ask the upstream to handle it and tag the bug as forwarded upstream - if the bug is still reproducible and has a known patch to fix it, I'll apply it to the Debian version, ask the upstream to merge and close the bug through the changelog during the next upload I think most bugs are not reproducible anymore because they are aged. I initially wrote this changelog header to apology for my lack of time regarding those bugs. I hope this time it's clear enough and that this would close the conversation now because I prefer spending more time on the fixes and less on the mailing lists. If you'd like to spend more time on the packages too, I'll be glad to welcome you as a co-maintainer. Please let me know. Thanks. -- Cyril Bouthors pgpbADWgnEmVQ.pgp Description: PGP signature
Re: Proper way of closing *old* bugs
On Sat, Apr 08, 2006 at 05:55:05PM -0500, Adam Majer wrote: My question is, is it now appropriate to use the changelog as a crutch to close bugs that have nothing to do with the upload? No; however, in this case, the bugs *did* have something to do with the upload. I was always under impression that *old* bugs should be closed by sending an email to [EMAIL PROTECTED] saying that you are closing it because it was fixed some time ago, etc.. etc.. Right, but that only applies if they have been fixed *in previous versions of the Debian package*. This upload is about bugs having been fixed in previous versions *of the upstream package*, which is not the same thing. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proper way of closing *old* bugs
Matthew Palmer [EMAIL PROTECTED] writes: There's some debate over whether closing upstream bugs in the changelog is OK, like so: * New upstream version. (Closes: #N) - The bar is now frobbed correctly. (Closes: #X) - No longer trip over our shoelaces. (Closes: #Y) * Random package installation failures stopped. (Closes: #) Some people think that it shouldn't be done ever, since it's not a change that the maintainer explicitly made, but others think that it's OK when done like that shown above, as it preserves all of the useful information. I think this case is reasonable. The specific upload of the new upstream fixes the named bugs. The version tracking of the BTS will correctly show those bugs as open/closed depending on the version queried and apt-listchanges will inform users correctly about bug fixes too. Descriptive entries detailing what the bug was that upstream fixed (bar is now frobbed correctly) are especialy helpfull. Just saing New upstream and then list a ton of bugs can be uninformative but with details per bug number I find that perfectly alright. But I can't think of *any* discussion which has ended with people claiming that closing random bugs is OK in an upload. How would you even describe it in the changelog? * The bug has magically disappeared. (Closes: #NNN) Uhhh... I doubt it. That is nasty. :) - Matt MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proper way of closing *old* bugs
It seems to me that, in this case (and correct me if I'm wrong), the package hasn't been updated from upstream for a long time, and so the difference between the old version and the new version fixes the stack of old bugs (( even though it wasn't _this specific version_ where the bug was fixed )). Now, if the bug has been (contrary to my reading) fixed for a long time, and just not reported as fixed, then I can see it being misleading to fix the bug via the changelog. If it's a case of being lazy, then you can just something like: while read bug notes ; do ( echo bug $bug was fixed a long time ago ; echo $notes | fmt ) | Mail [EMAIL PROTECTED] done EOF 42 A mouse did it 31415 Used a circular log 42923 Mikie did it. EOF Matthew Palmer wrote: On Sat, Apr 08, 2006 at 05:55:05PM -0500, Adam Majer wrote: Cyril Bouthors wrote: On 3 Apr 2006, Adam Majer wrote: But the correct method of closing bugs is to send a message to [EMAIL PROTECTED] with the explanation of the fix and not in the changelog. Well, at least not in the way you seem to intend. The bugs closed in changelogs are suppose to be bugs closed due to the changes from the previous version to the current version. If you only mean to do, * Close bugs that were fixed VERY long time ago (closes: #123,#234,#345,#456,#567,#678,#789,) then I don't think that is appropriate use of the changelog. Closing bugs through the changelog is an officially supported method and most DDs close bugs that way. Submitters receive a detailed notification by email as soon as the package is uploaded. I have no special mean to close bugs without informing the submitters with a clear and detailed explanation as I always did with all my packages. I'm stunned that anyone still thinks that closing unrelated bugs in a changelog is a good idea. [EMAIL PROTECTED] sends the detailed close message to the submitter, and it doesn't make it look like the problem was fixed in that version (which, of course, it wasn't). My question is, is it now appropriate to use the changelog as a crutch to close bugs that have nothing to do with the upload? I was always under impression that *old* bugs should be closed by sending an email to [EMAIL PROTECTED] saying that you are closing it because it was fixed some time ago, etc.. etc.. Absolutely. There's some debate over whether closing upstream bugs in the changelog is OK, like so: * New upstream version. (Closes: #N) - The bar is now frobbed correctly. (Closes: #X) - No longer trip over our shoelaces. (Closes: #Y) * Random package installation failures stopped. (Closes: #) Some people think that it shouldn't be done ever, since it's not a change that the maintainer explicitly made, but others think that it's OK when done like that shown above, as it preserves all of the useful information. But I can't think of *any* discussion which has ended with people claiming that closing random bugs is OK in an upload. How would you even describe it in the changelog? * The bug has magically disappeared. (Closes: #NNN) Uhhh... I doubt it. - Matt -- Stephen Samuel +1(778)861-7641 [EMAIL PROTECTED] http://www.bcgreen.com/ Powerful committed communication. Transformation touching the jewel within each person and bringing it to light. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proper way of closing *old* bugs
Stephen Samuel [EMAIL PROTECTED] wrote: It seems to me that, in this case (and correct me if I'm wrong), the package hasn't been updated from upstream for a long time, and so the difference between the old version and the new version fixes the stack of old bugs (( even though it wasn't _this specific version_ where the bug was fixed )). [...] Does not look like that. Afaict current upstream is still gnuplot 4.0.0, released 2004. And 4.0.0-1 has been uploaded to unstable on 2004-05-27. cu andreas -- The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal vision of the emperor's, and its inclusion in this work does not constitute tacit approval by the author or the publisher for any such projects, howsoever undertaken.(c) Jasper Ffforde -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proper way of closing *old* bugs
On 9 Apr 2006, Adam Majer wrote: My question is, is it now appropriate to use the changelog as a crutch to close bugs that have nothing to do with the upload? Adam, Apparently you still haven't understood my changelog nor my email: I haven't closed any bug that have nothing to do with the upload. -- Cyril Bouthors pgpawg32cFh3r.pgp Description: PGP signature
Re: Proper way of closing *old* bugs
On Sat, Apr 08, 2006 at 05:55:05PM -0500, Adam Majer wrote: Cyril Bouthors wrote: On 3 Apr 2006, Adam Majer wrote: But the correct method of closing bugs is to send a message to [EMAIL PROTECTED] with the explanation of the fix and not in the changelog. Well, at least not in the way you seem to intend. The bugs closed in changelogs are suppose to be bugs closed due to the changes from the previous version to the current version. If you only mean to do, * Close bugs that were fixed VERY long time ago (closes: #123,#234,#345,#456,#567,#678,#789,) then I don't think that is appropriate use of the changelog. Closing bugs through the changelog is an officially supported method and most DDs close bugs that way. Submitters receive a detailed notification by email as soon as the package is uploaded. I have no special mean to close bugs without informing the submitters with a clear and detailed explanation as I always did with all my packages. I'm stunned that anyone still thinks that closing unrelated bugs in a changelog is a good idea. [EMAIL PROTECTED] sends the detailed close message to the submitter, and it doesn't make it look like the problem was fixed in that version (which, of course, it wasn't). My question is, is it now appropriate to use the changelog as a crutch to close bugs that have nothing to do with the upload? I was always under impression that *old* bugs should be closed by sending an email to [EMAIL PROTECTED] saying that you are closing it because it was fixed some time ago, etc.. etc.. Absolutely. There's some debate over whether closing upstream bugs in the changelog is OK, like so: * New upstream version. (Closes: #N) - The bar is now frobbed correctly. (Closes: #X) - No longer trip over our shoelaces. (Closes: #Y) * Random package installation failures stopped. (Closes: #) Some people think that it shouldn't be done ever, since it's not a change that the maintainer explicitly made, but others think that it's OK when done like that shown above, as it preserves all of the useful information. But I can't think of *any* discussion which has ended with people claiming that closing random bugs is OK in an upload. How would you even describe it in the changelog? * The bug has magically disappeared. (Closes: #NNN) Uhhh... I doubt it. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
