[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [Xen-users] xen forum

On Wed, 22 May 2013 17:18:58 +0100, George Dunlap <george.dunlap@xxxxxxxxxxxxx> wrote:
On 22/05/13 16:24, Gordan Bobic wrote:
On Wed, 22 May 2013 11:20:49 +0100, George Dunlap <George.Dunlap@xxxxxxxxxxxxx> wrote:

I believe both mailing lists are great but there are so may postings
many issues get missed. There are some bugs that hand never been
because developers are unaware of it. I just setup forum for xen
users at
sam.hebe.us/forums please be free to join

It would be easier for us if the bug reports and such were posted on
Please consult http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
doing it.

Surely a bug-tracking system that emails all reports to xen-devel automatically would cover the best of both worlds, would it not?

Not unless developers can reply to the bug by hitting reply in their

Please drop the forum idea. Xen should use a proper bug tracking
system like Bugzilla (which allows replying to bugs by clicking
"Reply" in MUA).
Take a look at: http://www.bugzilla.org/docs/4.0/en/html/api/email_in.html


Along with a wiki for documentation that is actually kept updated when features are added/removed/changed and more importantly, that clearly states if/when obvious features are unexpectedly and conspicuously missing (e.g.
domU config file method of passing multiple USB devices to domU).

So the thing here is that I don't think any of the active developers
knew there was that limitation.  As soon as I discovered it, I just
fixed it (which is why 4.3 will have support for passing multiple USB
devices in the config file).

If you find other obvious missing features like that, please mention them on the list, and/or suggest them in the xen.org uservoice page:

Somebody mentioned it before. Here's a thread from 2009:

I think you are further strengthening the case for the list being
too leaky as a method of reporting things like this.

The question isn't about it being leaky, the question is attracting
the attention of someone who can do something about it.  If someone
had posted this on our bugzilla four years ago,

Oh wait - they did. And it was 6 years ago:

it would also still be
there today -- unless someone had actively looked through the list and
brought it to someone's attention.  That e-mail was on the xen-users
mailing list -- not the best place unfortunately for getting the
attention of developers. If no one did that for xen-users, why do you
think they would do it for a bugzilla?

The only point I can see being made here that the problem isn't the
medium but the attitude. With the list it is easy to ignore things.
With a bug tracking system, at least there is some kind of a sanely
organized database where issues can be tracked without relying
on chaos and random chance for something to get noticed.

What full-time developers typically do is to go through the xen-devel
mailing list every day looking for e-mails that are relevant to them.
When they find a bug report they think pertains to them, they put it
on their personal list and ask more questions about it to determine if it really is a bug, and if it really has to do with something in their
own area or in someone else's.  When they determine that it is a bug
and is in their area, they put it on their list of things to fix, and
get to it when it fits with their current priorities.

The key process in this step is "detecting signal in the noise" --
finding what's relevant in what's not relevant.  On a mailing list,
the "signal to noise" ratio is a function of how many messages there
are and what percentage of them pertain to you; as Xen grows as as
project, that ratio is lower, and so mail is sometimes dropped.

OK, then how about this: Have a bug tracking system with different
project sub-sections explicitly definced (e.g. usb passthrough,
pci passthrough, memory management, documentation, etc.) and each
developer can be assigned to one of those groups. That way when
a user files a bug report, they get an email about it if they
are working on that particular subsystem. It means they don't get
all the noise about the other subsystems they aren't familiar with.

With a single mailing list containing everything, signal is much
more difficult to pick out.

Unless you are trying to make the point that bug reports being
more easily ignorable is a good thing, in which case I give up. :)

But the problem isn't actually better on a bugzilla.  If I'm scanning
through bugs, I still need to find out which bugs are relevant to me.
The "signal to noise" ratio in this case, however, is the number of
open bugs -- which will grow linearly with time, as opposed to being a
constant based on the size of the project.

What bugzilla is *worse* for is discussing what the problem is and
coming up with a solution. Mail is much more suited for that purpose.

The two are not mutually exclusive. It has been pointed out that
Bugzilla has a 2-way mail API.

What we need is people who report / complain about bugs / deficiences
in a constructive way.

More like nag about a problem enough to get somebody to pay attention
and hope that the attention it gets isn't being added to the killfile.

Ideally the reporter would keep "Keep bugging
the list every so often until I'm told 'No'" on their own to-do list.

This sounds to me very much like a method for filtering bugs not
by relevance but by reporter persistence. Is that _really_ the
image this project wants to have regarding it's view on how seriously
bug reports are taken?

It would also be great if we had more experienced users helping to
make bug reports better, and then helping bring bug reports /
deficiencies to the attention of appropriate maintainers and
developers. Pasi I know has played this role, but it wouldn't hurt to
have more people get an idea who might be the best person to talk to
about a particular issue.

I think these are separate issues. A bug minder is really a different
responsibility from somebody primarily dealing with helping users
get things working. Unless most users asking for help are failing to
get things working due to a bug (which would be a rather damning
evaluation of the bugginess of the project given the list bandwidth).


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.