Re: [opensuse-factory] Bug handling
Hello, Am Mittwoch, 31. Mai 2006 11:55 schrieb Andreas Jaeger: > Andreas Hanke <[EMAIL PROTECTED]> writes: > > What happens if a report gets lost in NEEDINFO status even though > > the requested information was indeed provided. [...] > > If a person without any relation to the bug notices that, is this > > person allowed to "step in" and reset the NEEDINFO status? > > Yes, everybody is allowed to change that, so go ahead if you find > one, Well, more or less... http://en.opensuse.org/Bug_Reporting_FAQ basically asks for resetting needinfo, but also contains the following paragraph: --- Please note that bugs which are assigned to the BNC-Screening-Team (mainly YaST- and X11-related problems) initially or during the process should not be set from NEEDINFO to ASSIGNED by the reporter or the person the information was requested from. This is because a change of this status almost always involves a reassignment which is done by this team. Changing this status might cause the specific bug to appear on the wrong listing and might therefore be not handled (reassigned) efficiently. Thank you for taking this into account. --- Sorry, but this is not very user-friendly and confusing (some assignees want needinfo reset, others won't). The result will probably be that people won't reset needinfo for other assignees because their first bugzilla contact often is the screening team :-( Other people (like me) will always reset needinfo (without checking the assignee ;-) after providing the requested information and never noticed that the screening team overlooked one of my bugs. Summary: I don't understand why the screening team prefers bugs to be kept in needinfo state - maybe you should ask them if this is really a good idea... Regards, Christian Boltz -- In its default setup, Windows XP on the Internet amounts to a car parked in a bad part of town, with the doors unlocked, the key in the ignition and a Post-It note on the dashboard saying, "Please don't steal this". [Washington Post, 23.8.2003] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Bug handling
On Wed, May 31, 2006 at 11:24:23AM +0200, Andreas Hanke wrote: > Hi, > > and yet another Bug-handling related question: I have also one. How long after nothing has happend to a bug should you start taking action again and what is the correct procedure to 'ping' it? -- houghi http://houghi.org http://www.plainfaqs.org/linux/ http://www.netmeister.org/news/learn2quote.html > > Today I went outside. My pupils have never been tinier... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Bug handling
Andreas Hanke <[EMAIL PROTECTED]> writes: > Hi, > > and yet another Bug-handling related question: > > What happens if a report gets lost in NEEDINFO status even though the > requested information was indeed provided. I.e., a bug is NEEDINFO'd to > the reporter, the reporter provides the information but forgets to reset > the NEEDINFO status. > If a person without any relation to the bug notices that, is this person > allowed to "step in" and reset the NEEDINFO status? Yes, everybody is allowed to change that, so go ahead if you find one, Andreas -- Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 pgpgrpQh3XpsI.pgp Description: PGP signature
Re: [opensuse-factory] Bug handling
Hi, and yet another Bug-handling related question: What happens if a report gets lost in NEEDINFO status even though the requested information was indeed provided. I.e., a bug is NEEDINFO'd to the reporter, the reporter provides the information but forgets to reset the NEEDINFO status. If a person without any relation to the bug notices that, is this person allowed to "step in" and reset the NEEDINFO status? Andreas Hanke - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Bug handling
lør, 27,.05.2006 kl. 09.33 +0200, skrev [EMAIL PROTECTED]: snip > > Precisely, in this case it's about the problem of not being able to mount > floppies from within GNOME. The error message is "Method "Mount" with > signature "ssas" on interface "org.freedesktop.Hal.Device.Volume" doesn't > exist". > > I guess that this is known as #164327. There is a publicly accessible > duplicate #175590 and many similar, related but not-quite-duplicate ones: > > #152078 (same error message, but reported to and fixed in KDE, not GNOME) snip > Andreas Hanke I have the same issue... Open a terminal (as user) and type: mount /media/floppy Works like a charm for now. When that is said, I'd also like to know whats going on with that bug. Bjørn Lie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Bug handling
Hi, may I attach a similar (and most probably already asked...) question here? Is there a general rule what to do with publicly accessible reports that are duplicates of already known, not publicly accessible ones. In most cases the not publicly accessible original will remain private. I'm not questioning this policy in general, but are exceptions possible? Like "If there are more than publicly accessible duplicates, let's make the original one public as well so people can actually know what's going on". Precisely, in this case it's about the problem of not being able to mount floppies from within GNOME. The error message is "Method "Mount" with signature "ssas" on interface "org.freedesktop.Hal.Device.Volume" doesn't exist". I guess that this is known as #164327. There is a publicly accessible duplicate #175590 and many similar, related but not-quite-duplicate ones: #152078 (same error message, but reported to and fixed in KDE, not GNOME) #159589 (private, duplicate of the above) #164488 (another duplicate, for KDE) #152542 (yet another one, for KDE) #154652 (yet another one, for KDE #155574 (the last one I found, again for KDE) Specifically I'd like to know: - Is it known that this problem is fixed for KDE, but still present in GNOME (the publicly accessible #175590 doesn't say anything about the desktop environment explicitly), - Where is the origin of the problem, in a GNOME library (like it was in kdebase3 for KDE) or in hal/dbus itself, - Is it a problem in a setup script or config file that I can fix myself or does fixing this problem require a recompiled package, - Can I forget about it (aka. "don't use floppies") or are there plans to fix this for SL 10.1. Andreas Hanke -- Bis zu 70% Ihrer Onlinekosten sparen: GMX SmartSurfer! Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Bug handling
On 24 May 2006 at 16:04, Marcus Meissner wrote: > On Wed, May 24, 2006 at 04:57:55PM +0300, Andras Mantia wrote: > > Hi, > > > > Can someone from SUSE tell me how bug handling is done there? I mean, > > if there is a bug reported for some version and is not fixed in that > > version, is it taken in account for upcoming versions or it is just > > forgotten? An example: > > - a bug (like #176249 and previously #148638) is reported for 10.0 > > - it was closed with WONTFIX as the change cannot be made to a released > > product > > Should not have happened. In this case the bug should be assigned > to the next product. Hi! I also think this is bad, because when you search the original profduct for the bug, you won't find it, and you're going to make a report that will be closed as duplicate. I'd prefer a solution like a new field named "Fix scheduled for release:". Moving the bug report from SuSE release to SuSE release isn't helpful to anyone. [...] Regards Ulrich - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Bug handling
On Wednesday 24 May 2006 17:04, Marcus Meissner wrote: > On Wed, May 24, 2006 at 04:57:55PM +0300, Andras Mantia wrote: > > Hi, > > > > Can someone from SUSE tell me how bug handling is done there? I > > mean, if there is a bug reported for some version and is not fixed > > in that version, is it taken in account for upcoming versions or it > > is just forgotten? An example: > > - a bug (like #176249 and previously #148638) is reported for 10.0 > > - it was closed with WONTFIX as the change cannot be made to a > > released product > > Should not have happened. In this case the bug should be assigned > to the next product. > > > - the bug is still present in 10.1 (somebody reports again) > > - the bug is closed again as "it's too late and risky to do it" > > Same as above. I reopened in both cases. ;-) > You can reassign it to the next product, right now if possible. > > If it is still in the codebase, say so, reopen it, move it to the > next product. Well, I cannot test the upcoming 10.2, so I cannot just reassign. ;-) But I make sure at least to keep the bugs open as still as it is present in versions that I test. Andras -- Quanta Plus developer - http://quanta.kdewebdev.org K Desktop Environment - http://www.kde.org pgpguy6buf3CI.pgp Description: PGP signature
Re: [opensuse-factory] Bug handling
On Wed, May 24, 2006 at 04:57:55PM +0300, Andras Mantia wrote: > Hi, > > Can someone from SUSE tell me how bug handling is done there? I mean, > if there is a bug reported for some version and is not fixed in that > version, is it taken in account for upcoming versions or it is just > forgotten? An example: > - a bug (like #176249 and previously #148638) is reported for 10.0 > - it was closed with WONTFIX as the change cannot be made to a released > product Should not have happened. In this case the bug should be assigned to the next product. > - the bug is still present in 10.1 (somebody reports again) > - the bug is closed again as "it's too late and risky to do it" Same as above. > - the bug is still present and will be possibly present in 10.2 (unless > it's "fixed" upstream) > > (The upcoming possible scenario is: > - somebody reports "still present in 10.2" in a new bug > - it get's closed as "too late now for 10.2, maybe 10.3) > > The problem I have is not the fact that is not fixed, but the fact that > the bug report is closed even if it is present (and gets forgotten). > > In KDE we do the following: if a bug is reported for version X it is > considered to be present in all versions > X unless somebody says > otherwise, but in case of SUSE this doesn't seem to be the case. > > Please enlighten me. ;-) You can reassign it to the next product, right now if possible. If it is still in the codebase, say so, reopen it, move it to the next product. Ciao, Marcus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[opensuse-factory] Bug handling
Hi, Can someone from SUSE tell me how bug handling is done there? I mean, if there is a bug reported for some version and is not fixed in that version, is it taken in account for upcoming versions or it is just forgotten? An example: - a bug (like #176249 and previously #148638) is reported for 10.0 - it was closed with WONTFIX as the change cannot be made to a released product - the bug is still present in 10.1 (somebody reports again) - the bug is closed again as "it's too late and risky to do it" - the bug is still present and will be possibly present in 10.2 (unless it's "fixed" upstream) (The upcoming possible scenario is: - somebody reports "still present in 10.2" in a new bug - it get's closed as "too late now for 10.2, maybe 10.3) The problem I have is not the fact that is not fixed, but the fact that the bug report is closed even if it is present (and gets forgotten). In KDE we do the following: if a bug is reported for version X it is considered to be present in all versions > X unless somebody says otherwise, but in case of SUSE this doesn't seem to be the case. Please enlighten me. ;-) Andras -- Quanta Plus developer - http://quanta.kdewebdev.org K Desktop Environment - http://www.kde.org pgpLCEQfcMBrr.pgp Description: PGP signature
