ubuntu-x-swat team mailing list archive

[Geir Ove Myhr <gomyhr@xxxxxxxxx>]

On Fri, Jan 22, 2010 at 11:00 AM, Paul Perkins <catmatist@xxxxxxxxx> 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.