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

[Gordan Bobic <gordan@xxxxxxxxxx>]

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
> > > > > > > > > that
> > > > > > > > > many issues get missed. There are some bugs that hand never 
> > > > > > > > > been
> > > > > > > > > resolved
> > > > > > > > > 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
> > > > > > > > xen-devel.
> > > > > > > > Please consult 
> > > > > > > > http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
> > > > > > > > when
> > > > > > > > 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
> > > > > > MUA.
> > > > >
> > > > > 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
> > > >
> > > > +1
> > > >
> > > > 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:
> > >  http://xenorg.uservoice.com
> > Somebody mentioned it before. Here's a thread from 2009:
> > http://lists.xen.org/archives/html/xen-users/2009-10/msg00010.html
> >
> > 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:
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=907

> 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).

Gordan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel