On Fri, Jan 22, 2010 at 11:00 AM, Paul Perkins <catmat...@gmail.com> wrote: >>> We will get fewer bug reports, those that we get will be of higher quality, >>> and we will be able to handle a greater >>> fraction than what we do today? ;-)
Note that this was a joke... We certainly don't want to alienate users on purpose in order to achieve this. > I understand those goals. I see the current process as sacrificing those > goals in favor of generating some good looking (but misleading) > statistics about the quality of the code that gets into Ubuntu. I don't get this. What parts of the current process are you referring to? Certainly there are things to be improved, but this is not a good place to make it happen. I don't understand what you meed by generating statistics. For me, bug reports are tools for fixing bugs. Bug reports that do not have and will not get sufficient information for someone to act on them are better closed so that developers and triagers rather spend time on reading bug reports where we have a chance of doing something about it. > If Ubuntu wants fewer bug reports that they don't have the manpower to take > a serious look at, they should communicate better about what kinds of > reports will get a serious look, and what won't, at a point in the > process before someone wastes their time generating a report that is > doomed to be ignored. That would be nice, but I don't see a practical way of doing this. Especially, since factors such as how often a bug is reported, how many users are affected, how much spare time volunteers have, etc. If you have any good ideas I hope you can find a good place to communicate them. This is not one, but maybe http://brainstorm.ubuntu.com ? > And Ubuntu would generate less ill-will if they > had a bug status that says "even if this is a real bug, we will never > have time to fix it in this release anyway" and used it when appropriate > instead of stringing the user along asking for ever more information > that will never be used. I don't see why this cannot be done with a comment. Also, bugs are most often fixed only in the next release unless it has a big impact and is the fix has a low risk of regressions. Most (but not all) bugs reported to Ubuntu are bugs in the software that ubuntu merely packages, so what we can do is to help collect the information that the upstream projects requires and report the bugs there. Typically, upstreams don't consider bugs reported against anything but their newest software, and therefore we have ask people to test newer releases. > I'm not whining about not getting the support I'm not paying for. I'm > whining about being lied to. I'm sorry if you're feeling you are being lied to. I don't think anyone would lie to you on purpose, but perhaps the uncoordinated nature of volunteers makes you feel this way (one would say that we need X and Y in order to proceed (which is true), then even after X and Y are in place there is no developer who has time to look at it -- unfortunately there is no way for the triager to know this). It would be nice if we could back to the actual bug here. I don't blame you if you don't have the time to test and get a full backtrace with Lucid, but please understand that if that is the case we would like to close this bug report so that we don't keep revisiting it. If you have any ideas for improvement of the bug processing, I hope you can find an appropriate place to post them. I have mentioned brainstorm and there may be forums or mailing lists. -- [i945gm] x server crashes at random times (karmic) https://bugs.launchpad.net/bugs/509468 You received this bug notification because you are a member of Ubuntu-X, which is subscribed to xserver-xorg-video-intel in ubuntu. _______________________________________________ Mailing list: https://launchpad.net/~ubuntu-x-swat Post to : ubuntu-x-swat@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-x-swat More help : https://help.launchpad.net/ListHelp