Re: A way _not_ to handle bugs
On Wed, May 04, 2005 at 09:36:39AM -0700, Thomas Bushnell BSG wrote: Adrian Bunk [EMAIL PROTECTED] writes: What's the syntax for the email to [EMAIL PROTECTED] for adding a second submitter? I believe submitter [EMAIL PROTECTED],[EMAIL PROTECTED] works just fine. I'm quite surprised - I have to admit it actually works (and Colin immediately fixed two minor glitches with multiple submitters). cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A way _not_ to handle bugs
On Tue, May 03, 2005 at 12:40:21PM -0700, Steve Langasek wrote: ... On Tue, May 03, 2005 at 12:27:32PM +0200, Adrian Bunk wrote: first of all, if you downgrade a bug only a good hour after I upgraded it, it would be nice if you would: - Cc me - send a better explanation than This is not a missing dependency, feh If you are going to upgrade bugs to RC severity without talking to the maintainers first, it would be nice if you would be right. I have explained how this can produce non-working package combinations. If you do immediately lower the severity of a bug I raised the severity of again, could you please at least put my in the Cc header of the message you send to the BTS? In my testing, e.g. php4 from woody together with php4-mysql from sid is _not_ a working combination. $ apt-cache show php4-mysql Package: php4-mysql Version: 4:4.3.10-12 Depends: Depends: libc6 (= 2.3.2.ds1-4), libmysqlclient12, debconf (= 0.5) | debconf-2.0, phpapi-20020918, php4-common (= 4:4.3.10-12) ^^^ php4-mysql does not depend on php4 because the php4 package is *not* required to be installed in order for php4-mysql to be usable: installing any of the packages that provide phpapi-20020918 is sufficient to give you a php4 engine that can be used with php4-mysql. php4-mysql does not depend on any particular package providing the interface, because it has no way of knowing which one the user wants. The actual bug you're describing, therefore, is that the package relationships do not prevent you from having multiple PHP engines co-installed on your system that each provide different extension ABIs. This is a well-known bug that's irritating but not release-critical, and fixing it in sarge would not be at all straightforward. ... I'd consider this RC, and I think there might be good solutions that are not too difficult (e.g. Conflicts with the woody versions). But with this explanation, I understand your point. Communication is important. Why haven't you simply sent this explanation together with the control message and a Cc to me? This way I would have understood why you've downgraded it (whether I agree or not), and instead of becoming angry I would have thought about possible solutions for this bug (with this information I didn't have before). With this information you've now shared with me, my suggestion would be: All the packages providing phpapi-20020918 are built from the same source package. What about providing php-4.3.10 and letting packages like php4-mysql depend on such a version-specific provides? This would also make sense in cases like the ZTS transitions were you could change this Provides and automatically have all dependencies correct. Perhaps this suggestion doesn't work for some reason. But if you'd have shared the reasons why you don't think this issue was RC, you'd have helped me to think about ways how to fix this issue properly instead of sending an unfriendly email. I do admit that my email was overly unfriendly, but I hope you can understand that a bit of information from you would have been better. Steve Langasek cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A way _not_ to handle bugs
On Tue, May 03, 2005 at 09:24:34AM -0700, Thomas Bushnell BSG wrote: Adrian Bunk [EMAIL PROTECTED] writes: You seem to confuse this with bug closing. It's common practice to adjust the severity of a bug to a RC one if a RC issue was mistakenly reported as non-RC, and neither your Developers Reference nor your release team have ever disagreed with this practice. If you are also encountering the bug, then this is true, but I would expect you, being as knowledgeable as you are, to indicate that in the bug report and add yourself as a submitter. I didn't know a bug can have more than one submitter. What's the syntax for the email to [EMAIL PROTECTED] for adding a second submitter? ... Even Steve had always agreed that missing dependencies that break partial upgrades from woody were RC bugs And even in the email were he downgraded this bug he only wrongly stated This is not a missing dependency - not that missing dependencies weren't RC. This seems to indicate that he thinks there is a different explanation for the bug, and that while adding the package in question as a dependency makes it go away, this is not the correct fix. But I can only guess, as can you, which means it would be good to hold off until he can say rather than play BTS tag. That's exactly the problem. He has now given an explanation. As I've said in another email in this thread, giving this explanation in the email he lowered the severity with and sending me a Cc would have been perfect. Thomas cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A way _not_ to handle bugs
On Wed, May 04, 2005 at 01:33:52PM +0200, Adrian Bunk wrote: I didn't know a bug can have more than one submitter. What's the syntax for the email to [EMAIL PROTECTED] for adding a second submitter? Not entirely the answer you're looking for, but submit a duplicate bug and merge it. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A way _not_ to handle bugs
* Mark Brown ([EMAIL PROTECTED]) [050504 16:00]: On Wed, May 04, 2005 at 01:33:52PM +0200, Adrian Bunk wrote: I didn't know a bug can have more than one submitter. What's the syntax for the email to [EMAIL PROTECTED] for adding a second submitter? Not entirely the answer you're looking for, but submit a duplicate bug and merge it. No, don't do that. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A way _not_ to handle bugs
On Wed, May 04, 2005 at 04:01:52PM +0200, Andreas Barth wrote: * Mark Brown ([EMAIL PROTECTED]) [050504 16:00]: Not entirely the answer you're looking for, but submit a duplicate bug and merge it. No, don't do that. It's ugly as hell and may well annoy the maintainer by creating noise but it will do the job. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A way _not_ to handle bugs
On Tue, May 03, 2005 at 01:54:46PM -0500, Adam M. wrote: Adrian Bunk wrote: grave - serious isn't worth a discussion since there's not a big difference between them (both are RC) You are 100% wrong here. Why do we have bug severities then? Severities are there to inform the developer and the rest of the Debian world about the seriousness of the bug. I tend to stay away from packages that have grave or critical bugs against them before I read the bug report. So, let me refresh your mind about bug severities, ... Let me try to reformulate my point: important - serious or important - grave are worth a discussion, because if the bug is only important it's not unlikely sarge will ship with this bug. We could have a lengthy discussion whether there are possible scenarios where a specific dependency problem might cause data loss (which would make it grave) or whether it's only a policy violation. (If you are using php4-mysql on a web server to write the orders of your costumers into a database, couldn't this bug cause data loss?) But the practical differences between critical, grave and serious are small enough that if I send a bug as grave and you'd downgrade it to serious, I wouldn't care. - Adam cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A way _not_ to handle bugs
On 5/4/05, Adrian Bunk [EMAIL PROTECTED] wrote: On Tue, May 03, 2005 at 01:54:46PM -0500, Adam M. wrote: Adrian Bunk wrote: grave - serious isn't worth a discussion since there's not a big difference between them (both are RC) You are 100% wrong here. Why do we have bug severities then? Severities are there to inform the developer and the rest of the Debian world about the seriousness of the bug. I tend to stay away from packages that have grave or critical bugs against them before I read the bug report. So, let me refresh your mind about bug severities, ... Let me try to reformulate my point: important - serious or important - grave are worth a discussion, because if the bug is only important it's not unlikely sarge will ship with this bug. True, though important bugs can still be fixed during the freeze. We could have a lengthy discussion whether there are possible scenarios where a specific dependency problem might cause data loss (which would make it grave) or whether it's only a policy violation. (If you are using php4-mysql on a web server to write the orders of your costumers into a database, couldn't this bug cause data loss?) It wouldn't be grave just because it broke in my scenario. Data loss occurs when you think something worked, but it didn't. Or it corrupted/destroyed your data. I am ignorant to the actual bug though (haven't tried it myself). If the combination of php4 amd php4-mysql causes silent failures, then this is data loss and bug should be grave. If the application craps out with a visible error(s), or wrong output, then this bug does not cause data loss and is not grave. This doesn't mean all bugs are not important (not in BTS severity sense). I treat all bugs as important and try to resolve them. But the practical differences between critical, grave and serious are small enough that if I send a bug as grave and you'd downgrade it to serious, I wouldn't care. True, it doesn't really matter for the submitter if the bug is critical or serious if they only care that version X+1 of package doesn't go to testing due to the bug and X works. But severities do matter when you try to prioritize your work. For example, it is inappropriate for someone to file a critical bug just because they can't use feature X in program Alpha. Severties can and should be used to keep more buggy versions from progressing into testing. Severities are for practical reasons while many people still put their emotions into bug reports. This usually ends up with inflated bug severities. - Adam
Re: A way _not_ to handle bugs
Adrian Bunk [EMAIL PROTECTED] writes: If you do immediately lower the severity of a bug I raised the severity of again, could you please at least put my in the Cc header of the message you send to the BTS? No, that's not a requirement. If you want to receive notifications, you should add yourself as a submitter. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A way _not_ to handle bugs
Adrian Bunk [EMAIL PROTECTED] writes: What's the syntax for the email to [EMAIL PROTECTED] for adding a second submitter? I believe submitter [EMAIL PROTECTED],[EMAIL PROTECTED] works just fine. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A way _not_ to handle bugs
Adrian Bunk [EMAIL PROTECTED] writes: severity 306015 grave thanks Hi Steve, first of all, if you downgrade a bug only a good hour after I upgraded it, it would be nice if you would: - Cc me - send a better explanation than This is not a missing dependency, feh Looking at the bug log, it seems that you had no business increasing the severity in the first place. You didn't report the bug, you aren't the maintainer, and now you are playing BTS wars. It's up to the maintainer and Steve, secondarily it's up to the submitter of the bug, and it doesn't seem to concern you at all. This bug does not make the package unusable or mostly so because it has a trivial workaround available. So it was wrong of you to mark it grave, unless you are just seeking attention. It might be serious, but the submitter himself thought it was important. You didn't give any reasons for busting in and changing it. That's wrong. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A way _not_ to handle bugs
On Tue, May 03, 2005 at 08:30:22AM -0700, Thomas Bushnell BSG wrote: Adrian Bunk [EMAIL PROTECTED] writes: severity 306015 grave thanks Hi Steve, first of all, if you downgrade a bug only a good hour after I upgraded it, it would be nice if you would: - Cc me - send a better explanation than This is not a missing dependency, feh Looking at the bug log, it seems that you had no business increasing the severity in the first place. You didn't report the bug, you aren't the maintainer, and now you are playing BTS wars. It's up to the maintainer and Steve, secondarily it's up to the submitter of the bug, and it doesn't seem to concern you at all. You seem to confuse this with bug closing. It's common practice to adjust the severity of a bug to a RC one if a RC issue was mistakenly reported as non-RC, and neither your Developers Reference nor your release team have ever disagreed with this practice. The alternative would be to send a second bug for the same issue with the correct RC severity. If this makes you happy I can do this in the future. This bug does not make the package unusable or mostly so because it has a trivial workaround available. So it was wrong of you to mark it Once upon a time, Debian was famous for it's working upgrades. You can workaround many bugs - but why do you emphasize on the fact that there was a trivial workaround available if the fix for the bug is trivial? grave, unless you are just seeking attention. It might be serious, but the submitter himself thought it was important. You didn't give any reasons for busting in and changing it. That's wrong. grave - serious isn't worth a discussion since there's not a big difference between them (both are RC) Even Steve had always agreed that missing dependencies that break partial upgrades from woody were RC bugs And even in the email were he downgraded this bug he only wrongly stated This is not a missing dependency - not that missing dependencies weren't RC. Thomas cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A way _not_ to handle bugs
On Tue, May 03, 2005 at 08:30:22AM -0700, Thomas Bushnell BSG wrote: Looking at the bug log, it seems that you had no business increasing the severity in the first place. You didn't report the bug, you [...] So now just people who are affected by bugs are allowed to report them? And it's also forbidden to go through the list of open bugs and attempt to alert developers of important issues by raising the severity (if necessary)? While I have no opinion regarding the bug being discussed here, I believe that those few people who take the time to go through open bugs often do very valuable work, e.g. by identifying upgrade bugs which are waiting to happen the moment we release. Cheers, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: | \/¯| http://atterer.net | 0x888354F7 ¯ '` ¯ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A way _not_ to handle bugs
Adrian Bunk [EMAIL PROTECTED] writes: You seem to confuse this with bug closing. It's common practice to adjust the severity of a bug to a RC one if a RC issue was mistakenly reported as non-RC, and neither your Developers Reference nor your release team have ever disagreed with this practice. If you are also encountering the bug, then this is true, but I would expect you, being as knowledgeable as you are, to indicate that in the bug report and add yourself as a submitter. This bug does not make the package unusable or mostly so because it has a trivial workaround available. So it was wrong of you to mark it Once upon a time, Debian was famous for it's working upgrades. You can workaround many bugs - but why do you emphasize on the fact that there was a trivial workaround available if the fix for the bug is trivial? I agree that it's a bug. You seem to be saying that if it isn't an RC bug, then it's no bug at all. I think it is a bug--for exactly the reasons you state--but that doesn't make it grave. grave, unless you are just seeking attention. It might be serious, but the submitter himself thought it was important. You didn't give any reasons for busting in and changing it. That's wrong. grave - serious isn't worth a discussion since there's not a big difference between them (both are RC) Oh, I see, in your world there is RC and then nothing. The point you are missing is that it is the maintainer and the release manager who get to decide, not you. Even Steve had always agreed that missing dependencies that break partial upgrades from woody were RC bugs And even in the email were he downgraded this bug he only wrongly stated This is not a missing dependency - not that missing dependencies weren't RC. This seems to indicate that he thinks there is a different explanation for the bug, and that while adding the package in question as a dependency makes it go away, this is not the correct fix. But I can only guess, as can you, which means it would be good to hold off until he can say rather than play BTS tag. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A way _not_ to handle bugs
Richard Atterer [EMAIL PROTECTED] writes: On Tue, May 03, 2005 at 08:30:22AM -0700, Thomas Bushnell BSG wrote: Looking at the bug log, it seems that you had no business increasing the severity in the first place. You didn't report the bug, you [...] So now just people who are affected by bugs are allowed to report them? And it's also forbidden to go through the list of open bugs and attempt to alert developers of important issues by raising the severity (if necessary)? It seems. He didn't give any explanation for the increase in severity, which is why one can only guess at the motives. That's what was missing. The explanation has now been given, though the severity was incorrectly increased (it should only be serious according to the description). While I have no opinion regarding the bug being discussed here, I believe that those few people who take the time to go through open bugs often do very valuable work, e.g. by identifying upgrade bugs which are waiting to happen the moment we release. Oh, I agree completely! My point is that, having checked the bug and improved its severity does not entitle one to start playing BTS-tag. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A way _not_ to handle bugs
Adrian Bunk wrote: grave - serious isn't worth a discussion since there's not a big difference between them (both are RC) You are 100% wrong here. Why do we have bug severities then? Severities are there to inform the developer and the rest of the Debian world about the seriousness of the bug. I tend to stay away from packages that have grave or critical bugs against them before I read the bug report. So, let me refresh your mind about bug severities, |critical - |makes unrelated software on the system (or the whole system) break, or causes serious data loss, or introduces a security hole on systems where you install the package. |grave - |makes the package in question unusable or mostly so, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the package. |serious - |is a severe violation of Debian policy http://release.debian.org/sarge_rc_policy.txt (roughly, it violates a must or required directive), or, in the package maintainer's opinion, makes the package unsuitable for release. |important - |a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone. |normal - |the default value, applicable to most bugs. |minor - |a problem which doesn't affect the package's usefulness, and is presumably trivial to fix. |wishlist - |for any feature request, and also for any bugs that are very difficult to fix due to major design considerations. source: http://www.debian.org/Bugs/Developer#severities Thus, a bug that makes the package break like this falls under the important category (since an easy work around is available). *But*, the bug is also a violation of the Debian policy (ie. depends), so it becomes serious. Grave bugs are only there if the package doesn't work at all when you upgraded ALL depends to latest versions. - Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A way _not_ to handle bugs
severity 306015 important quit On Tue, May 03, 2005 at 12:27:32PM +0200, Adrian Bunk wrote: first of all, if you downgrade a bug only a good hour after I upgraded it, it would be nice if you would: - Cc me - send a better explanation than This is not a missing dependency, feh If you are going to upgrade bugs to RC severity without talking to the maintainers first, it would be nice if you would be right. In my testing, e.g. php4 from woody together with php4-mysql from sid is _not_ a working combination. $ apt-cache show php4-mysql Package: php4-mysql Version: 4:4.3.10-12 Depends: Depends: libc6 (= 2.3.2.ds1-4), libmysqlclient12, debconf (= 0.5) | debconf-2.0, phpapi-20020918, php4-common (= 4:4.3.10-12) ^^^ php4-mysql does not depend on php4 because the php4 package is *not* required to be installed in order for php4-mysql to be usable: installing any of the packages that provide phpapi-20020918 is sufficient to give you a php4 engine that can be used with php4-mysql. php4-mysql does not depend on any particular package providing the interface, because it has no way of knowing which one the user wants. The actual bug you're describing, therefore, is that the package relationships do not prevent you from having multiple PHP engines co-installed on your system that each provide different extension ABIs. This is a well-known bug that's irritating but not release-critical, and fixing it in sarge would not be at all straightforward. But that isn't even the problem the original submitter was reporting! The original submitter reported a problem with undefined symbol: php_sprintf, which has *nothing* to do with the php4 package! IIRC, the last time this error was reported it was a problem with bad caching from third-party accelerators, not a PHP bug at all; in *no* event could it be caused by a partial upgrade from woody. I knew this as a co-maintainer, and you didn't, and I shouldn't have to explain all this to you just to avoid having bug severities inflated when I could be doing something more productive with my time (and you with yours), like fixing real RC bugs. Please either explain why this is not a missing dependency or promise to be a little more careful in the future instead of blindly downgrading bugs. Please be a little more careful in the future instead of blindly upgrading bugs. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
