On Sat, 2014-07-19 at 19:49 +0200, Abou Al Montacir wrote: > Control: reopen -1 > > On Sat, 2014-07-19 at 17:03 +0000, Debian Bug Tracking System wrote: > ... > > > Missing information, dupe. > > > > > > Kind regards, > > > Andrei > > Hi Andrei, > > I don't think that missing information is enough argument to close a > bug. > > Hi AL Nik, > > Can you please provide more information about your issue. As the screen > is dead I understand that you may have issue to provide the required > information depending on your computer skills. Please find below some > hints, and maybe Andrei can provide more hints instead of closing this > bug again ;) > > If you have access to another computer, please consider logging into the > first one after resume (you need to have sshd installed or any other > deamon for remote access) then gain root access and provide output of > dmesg and other log files in /var/log like /var/log/pm-powersave.log. > > I'm not a specialist of such issues, but don't like to have user's > request closed abruptly. > > Cheers, > Abou Al Montacir Dear All, I want to take the occasion of this bug to enlighten how some DDs treat users, and especially newbes. This is a typical case of a user updating his laptop and suddenly is frustrated because some thing went wrong or a buggy package or nothing important but in his case he have a no more functional computer. The first reaction is to open a bug, a reaction I find natural and sane. But the maintainer closes immediately the bug without even asking for additional information. The user tries to figure out what is wrong and opens another bug. And finally both DD and user get frustrated. I'd like to bring this issue to d-d@l.d.o list in order to rich a consensus about good conduct when treating bugs. I was myself in several cases treated the same way and see some maintainers closing my bugs because they don't have the issue on their machines, or because they dont care of my use case. On my side I don't do this for my packages. i consider each problem report worth investigating and if I'm not interested in hunting such issue, I try to help the user doing so. It is probably kind of arrogance to think that a bug report is silly and is not worth spending our valuable time to understand its cause. One may argue that a ticket shall be open on real bugs, but here we don't even know if it is one. Maybe it is, so let's give time to the user investigating, and if he can not do it himself, give him hints. I'd really like having a king of code of conduct for bug handling, just like we have one for mailing lists. Cheers, Abou Al Montacir,
Attachment:
signature.asc
Description: This is a digitally signed message part