xen forum

xen forum

[jacek burghardt]

[-- Attachment #1.1: Type: text/plain, Size: 264 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 327 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: xen forum

[Gordan Bobic]

If the purpose of this is to raise visibility of bugs, a public bugzilla 
or similar would probably be a lot more useful than a forum.

Gordan

On 05/19/2013 04:09 PM, jacek burghardt 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 <http://sam.hebe.us/forums> please be
> free to join
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

Re: xen forum

[Joseph Glanville]

Personally I think a public bug/issue tracker would be great. At the
moment this is somewhat handled by the distros, Debian and Ubuntu
primarily but it would be nice if there was a canonical issue tracker.

On 19 May 2013 08:16, Gordan Bobic <gordan@bobich.net> wrote:
> If the purpose of this is to raise visibility of bugs, a public bugzilla or
> similar would probably be a lot more useful than a forum.
>
> Gordan
>
>
> On 05/19/2013 04:09 PM, jacek burghardt 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 <http://sam.hebe.us/forums> please be
>> free to join
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



-- 
CTO | Orion Virtualisation Solutions | www.orionvm.com.au
Phone: 1300 56 99 52 | Mobile: 0428 754 846

Re: xen forum

[Gordan Bobic]

I'm guessing this is no longer a relevant bugzilla, then?
http://bugzilla.xensource.com/bugzilla/

What concerns me is that there are bugs there that were filed as far 
back in 2009 and I'm still running into them today (found them by 
googling various issues I'm facing).

Is a separate, independent bugzilla and/or forum likely to get used 
more? If so, why? If not, then there is a different issue to solve in 
the first place.

Gordan

On 05/19/2013 05:36 PM, Joseph Glanville wrote:
> Personally I think a public bug/issue tracker would be great. At the
> moment this is somewhat handled by the distros, Debian and Ubuntu
> primarily but it would be nice if there was a canonical issue tracker.
>
> On 19 May 2013 08:16, Gordan Bobic <gordan@bobich.net> wrote:
>> If the purpose of this is to raise visibility of bugs, a public bugzilla or
>> similar would probably be a lot more useful than a forum.
>>
>> Gordan
>>
>>
>> On 05/19/2013 04:09 PM, jacek burghardt 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 <http://sam.hebe.us/forums> please be
>>> free to join
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xen.org/xen-devel
>>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>
>
>

Re: xen forum

[Konrad Rzeszutek Wilk]

On Sun, May 19, 2013 at 09:09:00AM -0600, jacek burghardt 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.

Re: xen forum

[Gordan Bobic]

 On Tue, 21 May 2013 10:29:17 -0400, Konrad Rzeszutek Wilk 
 <konrad.wilk@oracle.com> wrote:
> On Sun, May 19, 2013 at 09:09:00AM -0600, jacek burghardt 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?

 Gordan

Re: [Xen-users] xen forum

[Ian Campbell]

On Tue, 2013-05-21 at 15:57 +0100, Gordan Bobic wrote:
>  On Tue, 21 May 2013 10:29:17 -0400, Konrad Rzeszutek Wilk 
>  <konrad.wilk@oracle.com> wrote:
> > On Sun, May 19, 2013 at 09:09:00AM -0600, jacek burghardt 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.

Ian.

Re: [Xen-users] xen forum

[Bartek Krawczyk]

On 21 May 2013 17:04, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Tue, 2013-05-21 at 15:57 +0100, Gordan Bobic wrote:
>>  On Tue, 21 May 2013 10:29:17 -0400, Konrad Rzeszutek Wilk
>>  <konrad.wilk@oracle.com> wrote:
>> > On Sun, May 19, 2013 at 09:09:00AM -0600, jacek burghardt 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

Regards,
--
Bartek Krawczyk

Re: [Xen-users] xen forum

[Gordan Bobic]

On 05/22/2013 07:18 AM, Bartek Krawczyk wrote:
> On 21 May 2013 17:04, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> On Tue, 2013-05-21 at 15:57 +0100, Gordan Bobic wrote:
>>>   On Tue, 21 May 2013 10:29:17 -0400, Konrad Rzeszutek Wilk
>>>   <konrad.wilk@oracle.com> wrote:
>>>> On Sun, May 19, 2013 at 09:09:00AM -0600, jacek burghardt 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).

Gordan

Re: [Xen-users] xen forum

[Ian Campbell]

On Wed, 2013-05-22 at 07:55 +0100, Gordan Bobic wrote:
> 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

The beauty of a wiki is that anyone can edit or correct it.

We have regular documentation days where we are all (users and devs
alike) encouraged to work to improve the state of the wiki and other
documentation. 

http://wiki.xen.org/wiki/Xen_Document_Days

The state of the Xen documentation base has actually improved
considerably over the last year due to this initiative.

> (e.g. domU config file method of passing multiple USB devices to 
> domU).

I'm not sure what you are referring to here, the config file syntax is
documented in docs/man/xl.cfg.pod.5 which is installed as the xl.cfg(5)
manpage. It is also available online
http://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html and referenced
from the wiki e.g. http://wiki.xen.org/wiki/Xen_Man_Pages

This manpage contains:
        =item B<usbdevice=[ "DEVICE", "DEVICE", ...]>
        
        Adds B<DEVICE>s to the emulated USB bus. The USB bus must also be
        enabled using B<usb=1>. The most common use for this option is
        B<usbdevice=['tablet']> which adds pointer device using absolute
        coordinates. Such devices function better than relative coordinate
        devices (such as a standard mouse) since many methods of exporting
        guest graphics (such as VNC) work better in this mode. Note that this
        is independent of the actual pointer device you are using on the
        host/client side.
        
        Host devices can also be passed through in this way, by specifying
        host:USBID, where USBID is of the form xxxx:yyyy.  The USBID can
        typically be found by using lsusb or usb-devices.
        
        The form usbdevice=DEVICE is also accepted for backwards compatibility.
        
        More valid options can be found in the "usbdevice" section of the qemu
        documentation.

Ian.

Re: [Xen-users] xen forum

[George Dunlap]

On Wed, May 22, 2013 at 10:53 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Wed, 2013-05-22 at 07:55 +0100, Gordan Bobic wrote:
>> 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
>
> The beauty of a wiki is that anyone can edit or correct it.
>
> We have regular documentation days where we are all (users and devs
> alike) encouraged to work to improve the state of the wiki and other
> documentation.
>
> http://wiki.xen.org/wiki/Xen_Document_Days
>
> The state of the Xen documentation base has actually improved
> considerably over the last year due to this initiative.
>
>> (e.g. domU config file method of passing multiple USB devices to
>> domU).
>
> I'm not sure what you are referring to here, the config file syntax is
> documented in docs/man/xl.cfg.pod.5 which is installed as the xl.cfg(5)
> manpage. It is also available online
> http://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html and referenced
> from the wiki e.g. http://wiki.xen.org/wiki/Xen_Man_Pages
>
> This manpage contains:
>         =item B<usbdevice=[ "DEVICE", "DEVICE", ...]>

This is a new feature for 4.3 -- 4.2 and earlier don't support
multiple USB devices (including say, a host device and an emulated usb
tablet).

 -George

Re: [Xen-users] xen forum

[Gordan Bobic]

 On Wed, 22 May 2013 10:58:30 +0100, George Dunlap 
 <George.Dunlap@eu.citrix.com> wrote:
> On Wed, May 22, 2013 at 10:53 AM, Ian Campbell
> <Ian.Campbell@citrix.com> wrote:
>> On Wed, 2013-05-22 at 07:55 +0100, Gordan Bobic wrote:
>>> 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
>>
>> The beauty of a wiki is that anyone can edit or correct it.
>>
>> We have regular documentation days where we are all (users and devs
>> alike) encouraged to work to improve the state of the wiki and other
>> documentation.
>>
>> http://wiki.xen.org/wiki/Xen_Document_Days
>>
>> The state of the Xen documentation base has actually improved
>> considerably over the last year due to this initiative.
>>
>>> (e.g. domU config file method of passing multiple USB devices to
>>> domU).
>>
>> I'm not sure what you are referring to here, the config file syntax 
>> is
>> documented in docs/man/xl.cfg.pod.5 which is installed as the 
>> xl.cfg(5)
>> manpage. It is also available online
>> http://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html and 
>> referenced
>> from the wiki e.g. http://wiki.xen.org/wiki/Xen_Man_Pages
>>
>> This manpage contains:
>>         =item B<usbdevice=[ "DEVICE", "DEVICE", ...]>
>
> This is a new feature for 4.3 -- 4.2 and earlier don't support
> multiple USB devices (including say, a host device and an emulated 
> usb
> tablet).

 Is this an xl-only feature or will it work with xl as well?

 Gordan

Re: [Xen-users] xen forum

[George Dunlap]

On 22/05/13 16:27, Gordan Bobic wrote:
> On Wed, 22 May 2013 10:58:30 +0100, George Dunlap 
> <George.Dunlap@eu.citrix.com> wrote:
>> On Wed, May 22, 2013 at 10:53 AM, Ian Campbell
>> <Ian.Campbell@citrix.com> wrote:
>>> On Wed, 2013-05-22 at 07:55 +0100, Gordan Bobic wrote:
>>>> 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
>>>
>>> The beauty of a wiki is that anyone can edit or correct it.
>>>
>>> We have regular documentation days where we are all (users and devs
>>> alike) encouraged to work to improve the state of the wiki and other
>>> documentation.
>>>
>>> http://wiki.xen.org/wiki/Xen_Document_Days
>>>
>>> The state of the Xen documentation base has actually improved
>>> considerably over the last year due to this initiative.
>>>
>>>> (e.g. domU config file method of passing multiple USB devices to
>>>> domU).
>>>
>>> I'm not sure what you are referring to here, the config file syntax is
>>> documented in docs/man/xl.cfg.pod.5 which is installed as the xl.cfg(5)
>>> manpage. It is also available online
>>> http://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html and referenced
>>> from the wiki e.g. http://wiki.xen.org/wiki/Xen_Man_Pages
>>>
>>> This manpage contains:
>>>         =item B<usbdevice=[ "DEVICE", "DEVICE", ...]>
>>
>> This is a new feature for 4.3 -- 4.2 and earlier don't support
>> multiple USB devices (including say, a host device and an emulated usb
>> tablet).
>
> Is this an xl-only feature or will it work with xl as well?

It will work with both xl and xl, but not with xm. :-)

  -George

Re: [Xen-users] xen forum

[Gordan Bobic]

 On Wed, 22 May 2013 16:32:33 +0100, George Dunlap 
 <george.dunlap@eu.citrix.com> wrote:
> On 22/05/13 16:27, Gordan Bobic wrote:
>> On Wed, 22 May 2013 10:58:30 +0100, George Dunlap 
>> <George.Dunlap@eu.citrix.com> wrote:
>>> On Wed, May 22, 2013 at 10:53 AM, Ian Campbell
>>> <Ian.Campbell@citrix.com> wrote:
>>>> On Wed, 2013-05-22 at 07:55 +0100, Gordan Bobic wrote:
>>>>> 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
>>>>
>>>> The beauty of a wiki is that anyone can edit or correct it.
>>>>
>>>> We have regular documentation days where we are all (users and 
>>>> devs
>>>> alike) encouraged to work to improve the state of the wiki and 
>>>> other
>>>> documentation.
>>>>
>>>> http://wiki.xen.org/wiki/Xen_Document_Days
>>>>
>>>> The state of the Xen documentation base has actually improved
>>>> considerably over the last year due to this initiative.
>>>>
>>>>> (e.g. domU config file method of passing multiple USB devices to
>>>>> domU).
>>>>
>>>> I'm not sure what you are referring to here, the config file 
>>>> syntax is
>>>> documented in docs/man/xl.cfg.pod.5 which is installed as the 
>>>> xl.cfg(5)
>>>> manpage. It is also available online
>>>> http://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html and 
>>>> referenced
>>>> from the wiki e.g. http://wiki.xen.org/wiki/Xen_Man_Pages
>>>>
>>>> This manpage contains:
>>>>         =item B<usbdevice=[ "DEVICE", "DEVICE", ...]>
>>>
>>> This is a new feature for 4.3 -- 4.2 and earlier don't support
>>> multiple USB devices (including say, a host device and an emulated 
>>> usb
>>> tablet).
>>
>> Is this an xl-only feature or will it work with xl as well?
>
> It will work with both xl and xl, but not with xm. :-)

 Hmm... Are there any outstanding issues with xl and PCI / VGA 
 passthrough?

 I'm sure I read on the (possibly out of date) wiki that with xl
 PCI passthrough requires FLR, which 99% of devices lack (i.e. makes
 it useless to anyone wanting to do any kind of PCI passthrough).

 Perhaps I'll try my VMs with xl tonight and see what, if anything,
 breaks and raise it before time's up for 4.3 release...

 Gordan

Re: [Xen-users] xen forum

[Ian Campbell]

On Wed, 2013-05-22 at 16:52 +0100, Gordan Bobic wrote:
>  Perhaps I'll try my VMs with xl tonight and see what, if anything,
>  breaks and raise it before time's up for 4.3 release...

Today is a 4.3.0-rc2 test day so that would be rather timely ;-)

http://wiki.xen.org/wiki/Xen_Test_Days

Ian.

Re: [Xen-users] xen forum

[George Dunlap]

On 22/05/13 16:52, Gordan Bobic wrote:
> On Wed, 22 May 2013 16:32:33 +0100, George Dunlap 
> <george.dunlap@eu.citrix.com> wrote:
>> On 22/05/13 16:27, Gordan Bobic wrote:
>>> On Wed, 22 May 2013 10:58:30 +0100, George Dunlap 
>>> <George.Dunlap@eu.citrix.com> wrote:
>>>> On Wed, May 22, 2013 at 10:53 AM, Ian Campbell
>>>> <Ian.Campbell@citrix.com> wrote:
>>>>> On Wed, 2013-05-22 at 07:55 +0100, Gordan Bobic wrote:
>>>>>> 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
>>>>>
>>>>> The beauty of a wiki is that anyone can edit or correct it.
>>>>>
>>>>> We have regular documentation days where we are all (users and devs
>>>>> alike) encouraged to work to improve the state of the wiki and other
>>>>> documentation.
>>>>>
>>>>> http://wiki.xen.org/wiki/Xen_Document_Days
>>>>>
>>>>> The state of the Xen documentation base has actually improved
>>>>> considerably over the last year due to this initiative.
>>>>>
>>>>>> (e.g. domU config file method of passing multiple USB devices to
>>>>>> domU).
>>>>>
>>>>> I'm not sure what you are referring to here, the config file 
>>>>> syntax is
>>>>> documented in docs/man/xl.cfg.pod.5 which is installed as the 
>>>>> xl.cfg(5)
>>>>> manpage. It is also available online
>>>>> http://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html and referenced
>>>>> from the wiki e.g. http://wiki.xen.org/wiki/Xen_Man_Pages
>>>>>
>>>>> This manpage contains:
>>>>>         =item B<usbdevice=[ "DEVICE", "DEVICE", ...]>
>>>>
>>>> This is a new feature for 4.3 -- 4.2 and earlier don't support
>>>> multiple USB devices (including say, a host device and an emulated usb
>>>> tablet).
>>>
>>> Is this an xl-only feature or will it work with xl as well?
>>
>> It will work with both xl and xl, but not with xm. :-)
>
> Hmm... Are there any outstanding issues with xl and PCI / VGA 
> passthrough?
>
> I'm sure I read on the (possibly out of date) wiki that with xl
> PCI passthrough requires FLR, which 99% of devices lack (i.e. makes
> it useless to anyone wanting to do any kind of PCI passthrough).
>
> Perhaps I'll try my VMs with xl tonight and see what, if anything,
> breaks and raise it before time's up for 4.3 release...

Most of the core Xen developers don't use PCI pass-through on a regular 
basis becuase the vast majority of the customers of the companies we 
work for don't use it.  We rely on our users to test what is important 
for them.

So yes, if you want xl to work with PCI / VGA pass-thru, then please 
test it and let us know what doesn't work.

  -George

Re: [Xen-users] xen forum

[Gordan Bobic]

On 05/22/2013 04:52 PM, Gordan Bobic wrote:
> On Wed, 22 May 2013 16:32:33 +0100, George Dunlap
> <george.dunlap@eu.citrix.com> wrote:
>> On 22/05/13 16:27, Gordan Bobic wrote:
>>> On Wed, 22 May 2013 10:58:30 +0100, George Dunlap
>>> <George.Dunlap@eu.citrix.com> wrote:
>>>> On Wed, May 22, 2013 at 10:53 AM, Ian Campbell
>>>> <Ian.Campbell@citrix.com> wrote:
>>>>> On Wed, 2013-05-22 at 07:55 +0100, Gordan Bobic wrote:
>>>>>> 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
>>>>>
>>>>> The beauty of a wiki is that anyone can edit or correct it.
>>>>>
>>>>> We have regular documentation days where we are all (users and devs
>>>>> alike) encouraged to work to improve the state of the wiki and other
>>>>> documentation.
>>>>>
>>>>> http://wiki.xen.org/wiki/Xen_Document_Days
>>>>>
>>>>> The state of the Xen documentation base has actually improved
>>>>> considerably over the last year due to this initiative.
>>>>>
>>>>>> (e.g. domU config file method of passing multiple USB devices to
>>>>>> domU).
>>>>>
>>>>> I'm not sure what you are referring to here, the config file syntax is
>>>>> documented in docs/man/xl.cfg.pod.5 which is installed as the
>>>>> xl.cfg(5)
>>>>> manpage. It is also available online
>>>>> http://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html and referenced
>>>>> from the wiki e.g. http://wiki.xen.org/wiki/Xen_Man_Pages
>>>>>
>>>>> This manpage contains:
>>>>>         =item B<usbdevice=[ "DEVICE", "DEVICE", ...]>
>>>>
>>>> This is a new feature for 4.3 -- 4.2 and earlier don't support
>>>> multiple USB devices (including say, a host device and an emulated usb
>>>> tablet).
>>>
>>> Is this an xl-only feature or will it work with xl as well?
>>
>> It will work with both xl and xl, but not with xm. :-)
>
> Hmm... Are there any outstanding issues with xl and PCI / VGA passthrough?
>
> I'm sure I read on the (possibly out of date) wiki that with xl
> PCI passthrough requires FLR, which 99% of devices lack (i.e. makes
> it useless to anyone wanting to do any kind of PCI passthrough).
>
> Perhaps I'll try my VMs with xl tonight and see what, if anything,
> breaks and raise it before time's up for 4.3 release...

OK, I can confirm that my VM configs start OK using xl. Unfortunately, 
xl in 4.2 doesn't support usb-add, so I cannot pass the required USB 
devices through, over and above the one I can pass in the config file.

Will usb-add also be available in 4.3, in addition to the multi-device 
syntax in the config file?

Any chance of the multi-device syntax also being patched into xm for 4.3?

Gordan

Re: [Xen-users] xen forum

[George Dunlap]

On Wed, May 22, 2013 at 9:54 PM, Gordan Bobic <gordan@bobich.net> wrote:
> OK, I can confirm that my VM configs start OK using xl. Unfortunately, xl in
> 4.2 doesn't support usb-add, so I cannot pass the required USB devices
> through, over and above the one I can pass in the config file.
>
> Will usb-add also be available in 4.3, in addition to the multi-device
> syntax in the config file?

Unfortunately not. :-(  I did start the process, but unfortunately
rather too late in the release cycle, and the design of a proper
interface took a lot longer than I expected.  The good news is that we
are in really good shape to have the feature in 4.4, which we're
expecting to be in 6 months (or less) from the release for 4.3.

If you're using this personally, and you're really keen, you could
apply the most recent patchset that I posted (or I could send you a
rebased version).  From a technical standpoint it's very
straightforward, and I had the basic functionality working months ago
for HVM domains with qemu-upstream.  So the patchset should work
fairly reliably; just be aware that the interface (both in xl and
libxl) may change before the final release.

> Any chance of the multi-device syntax also being patched into xm for 4.3?

I think at this point it's unlikely.  Even if we had the patches, it's
too late in the release process to risk introducing a bug to implement
this feature.

There is an all-purpose work-around, however.  Basically all of the
device options are parsed from the config file and then transmuted
into qemu command-line parameters.  There's a field in the config file
that allows you to pass in a string of options directly.  If you
wanted to add more usb devices, you can do something like this:

extra="-usbdevice $dev1 -usbdevice $dev2"

Where $dev1 and $dev2 are the same syntax you would use in the
"usbdevice" field of the config file.

This can be used to access other qemu features that are not
implemented by xm or xl as well.  It would all be "use at your own
risk", but there's no reason most of it shouldn't just work out of the
box.

 -George

Re: [Xen-users] xen forum

[Ian Campbell]

On Thu, 2013-05-23 at 11:41 +0100, George Dunlap wrote:
> > Any chance of the multi-device syntax also being patched into xm for 4.3?
> 
> I think at this point it's unlikely.  Even if we had the patches, it's
> too late in the release process to risk introducing a bug to implement
> this feature.

Also since xend/xm is now deprecated (and has been since 4.2) I'm not
sure adding new features would be appropriate.

> There is an all-purpose work-around, however.  Basically all of the
> device options are parsed from the config file and then transmuted
> into qemu command-line parameters.  There's a field in the config file
> that allows you to pass in a string of options directly.  If you
> wanted to add more usb devices, you can do something like this:
> 
> extra="-usbdevice $dev1 -usbdevice $dev2"

Do you really mean "extra", I thought that was for extra bits tacked
onto the PV kernel command. Maybe it has this alternative meaning for
HVM guests though?

Under xl this option is "device_model_args". Not sure if xm had an
equivalent, dmargs rings a vague bell though.

Ian.

Re: [Xen-users] xen forum

[George Dunlap]

On 23/05/13 13:04, Ian Campbell wrote:
> On Thu, 2013-05-23 at 11:41 +0100, George Dunlap wrote:
>>> Any chance of the multi-device syntax also being patched into xm for 4.3?
>> I think at this point it's unlikely.  Even if we had the patches, it's
>> too late in the release process to risk introducing a bug to implement
>> this feature.
> Also since xend/xm is now deprecated (and has been since 4.2) I'm not
> sure adding new features would be appropriate.
>
>> There is an all-purpose work-around, however.  Basically all of the
>> device options are parsed from the config file and then transmuted
>> into qemu command-line parameters.  There's a field in the config file
>> that allows you to pass in a string of options directly.  If you
>> wanted to add more usb devices, you can do something like this:
>>
>> extra="-usbdevice $dev1 -usbdevice $dev2"
> Do you really mean "extra", I thought that was for extra bits tacked
> onto the PV kernel command. Maybe it has this alternative meaning for
> HVM guests though?
>
> Under xl this option is "device_model_args". Not sure if xm had an
> equivalent, dmargs rings a vague bell though.

Apparently I don't -- sorry, I just looked through my config files and 
that was a line commented out that looked like it did what I wanted.  
But apparently that's completely wrong.

And, looking through the xend code and config files, I can't seem to 
find an equivalent command.  OK, sorry for the misdirection. :-/

  -George

Re: [Xen-users] xen forum

[George Dunlap]

On Wed, May 22, 2013 at 7:55 AM, Gordan Bobic <gordan@bobich.net> wrote:
> On 05/22/2013 07:18 AM, Bartek Krawczyk wrote:
>>
>> On 21 May 2013 17:04, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>>>
>>> On Tue, 2013-05-21 at 15:57 +0100, Gordan Bobic wrote:
>>>>
>>>>   On Tue, 21 May 2013 10:29:17 -0400, Konrad Rzeszutek Wilk
>>>>   <konrad.wilk@oracle.com> wrote:
>>>>>
>>>>> On Sun, May 19, 2013 at 09:09:00AM -0600, jacek burghardt 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

 -George

Re: [Xen-users] xen forum

[Gordan Bobic]

 On Wed, 22 May 2013 11:20:49 +0100, George Dunlap 
 <George.Dunlap@eu.citrix.com> 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.

 Gordan

Re: [Xen-users] xen forum

[George Dunlap]

On 22/05/13 16:24, Gordan Bobic wrote:
> On Wed, 22 May 2013 11:20:49 +0100, George Dunlap 
> <George.Dunlap@eu.citrix.com> 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, 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?

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.

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.

What we need is people who report / complain about bugs / deficiences in 
a constructive way.  Ideally the reporter would keep "Keep bugging the 
list every so often until I'm told 'No'" on their own to-do list.  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.

  -George

Re: [Xen-users] xen forum

[Gordan Bobic]

 On Wed, 22 May 2013 17:18:58 +0100, George Dunlap 
 <george.dunlap@eu.citrix.com> wrote:
> On 22/05/13 16:24, Gordan Bobic wrote:
>> On Wed, 22 May 2013 11:20:49 +0100, George Dunlap 
>> <George.Dunlap@eu.citrix.com> 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

Re: [Xen-users] xen forum

[George Dunlap]

On 22/05/13 17:44, Gordan Bobic wrote:
>
>> 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.

This conversation is getting really negative, so I think we need to turn 
the direction a bit.

The developers want to be told about bugs so we can fix them; and we 
want users to have confidence in the software they're using.  Nobody is 
going to be added to a killfile for reporting a bug and asking about it 
a few times.

We've known for a while that important bugs sometimes get dropped, and 
we've already started working on solutions for it that fit with our 
existing workflow.  And obviously having a bugzilla that no one actually 
uses is much worse than just having no bugzilla at all. That needs to be 
sorted out.

As we've been looking at re-organizing the bug-reporting process, we've 
been mainly looking at how we can make it useful for developers, so that 
we can spend more time actually fixing bugs and writing new features.  
It seems maybe we've been focusing too much on that and not on the 
perspective of the users.

So thank you for bringing this up; hopefully we can come up with 
something that is the best for everyone.

  -George

Re: [Xen-users] xen forum

[Ian Murray]

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


My own experience is that posts (at least from me) are regularly missed/ignored on the devel list, including a signed patch, so I personally think a bug tracker would be a better option. Bug trackers don't (or at least shouldn't :) ) forget or miss. That's they're raison d'etre. I honestly don't know how anyone can do business using this list, but that's just my humble opinion.

As professional developer and application support bod myself, I wouldn't ask anybody to read that missive; I wouldn't get any bug reports ever!

Re: [Xen-users] xen forum

[Ian Campbell]

On Tue, 2013-05-21 at 16:04 +0100, Ian Murray wrote:
> 
> >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.
> >
> 
> 
> My own experience is that posts (at least from me) are regularly
> missed/ignored on the devel list, including a signed patch,

Do you have a link to that patch? As explained in the submission
guidelines http://wiki.xen.org/wiki/Submitting_Xen_Patches things do
fall through the gaps but it is the submitters responsibility to ping
and resend as necessary.

>  so I personally think a bug tracker would be a better option. Bug
> trackers don't (or at least shouldn't :) ) forget or miss.

That's irrelevant unless the people you are trying to communicate with
are regularly checking the BTS, which they are not.

Why would you expect to be more assured of a reply to your mails if a
bug tracker had automatically logged them?

>  That's they're raison d'etre. I honestly don't know how anyone can do
> business using this list, but that's just my humble opinion.

List policy includes retaining copies to people, so you don't need to
subscribe to send a bug report to the list.

Ian.

Re: [Xen-users] xen forum

[Ian Murray]

>>  My own experience is that posts (at least from me) are regularly
>>  missed/ignored on the devel list, including a signed patch,
> 
> Do you have a link to that patch? As explained in the submission
> guidelines http://wiki.xen.org/wiki/Submitting_Xen_Patches things do
> fall through the gaps but it is the submitters responsibility to ping
> and resend as necessary.

I starting going through the process of resubmitting (the process having completely changed) but then had a problem with git blocking changes to xendomains file. I asked a question about the issue on xen-dev which - guess what - got ignored. So, there is only so much one can do. :)

Original patch:-
http://lists.xen.org/archives/html/xen-devel/2011-06/msg01092.html

Follow up question in an attempt to resubmit:

http://lists.xen.org/archives/html/xen-devel/2013-03/msg01408.html

Both ignored. Gave up.


> 
>>   so I personally think a bug tracker would be a better option. Bug
>>  trackers don't (or at least shouldn't :) ) forget or miss.
> 
> That's irrelevant unless the people you are trying to communicate with
> are regularly checking the BTS, which they are not.

Well, if a maintainer who is trying to squish bugs is not using the bug tracker, then yes, it completely useless!

> 
> Why would you expect to be more assured of a reply to your mails if a
> bug tracker had automatically logged them?

I am not assured of a reply, but surely the idea of a tracking system is that bugs don't get forgotten about. In my case, I would have raised an issue against xendomains, hopefully stated wants seems to go wrong and either it sits there and is dealt with, batted back to me for more info, or willfully ignored. But never should it just get "lost in the cracks".

I'll shut up about it now, because whoever decides these things will do what they want, anyway.


> 
>>   That's they're raison d'etre. I honestly don't know how 
> anyone can do
>>  business using this list, but that's just my humble opinion.
> 
> List policy includes retaining copies to people, so you don't need to
> subscribe to send a bug report to the list.
> 
> Ian.
> 

Re: [Xen-users] xen forum

[Ian Campbell]

On Tue, 2013-05-21 at 17:00 +0100, Ian Murray wrote:
> 
> >>  My own experience is that posts (at least from me) are regularly
> >>  missed/ignored on the devel list, including a signed patch,
> > 
> > Do you have a link to that patch? As explained in the submission
> > guidelines http://wiki.xen.org/wiki/Submitting_Xen_Patches things do
> > fall through the gaps but it is the submitters responsibility to ping
> > and resend as necessary.
> 
> I starting going through the process of resubmitting (the process
> having completely changed)

The process (send a signed-off-by email to xen-devel) hasn't changed in
forever. Some of the tools which are convenient (but not required) to
use have changed recently and therefore some of the advice might have
changed.

>  but then had a problem with git blocking changes to xendomains file.
> I asked a question about the issue on xen-dev which - guess what - got
> ignored. So, there is only so much one can do. :)
> 
> Original patch:-
> http://lists.xen.org/archives/html/xen-devel/2011-06/msg01092.html
> 
> Follow up question in an attempt to resubmit:
> 
> http://lists.xen.org/archives/html/xen-devel/2013-03/msg01408.html
> 
> Both ignored. Gave up.

FWIW the answer is that .gitignore is wrong and using -f would have been
fine if you couldn't see where .gitignore was wrong (and
fixing .gitignore would have been fine if you could see where).

> > Why would you expect to be more assured of a reply to your mails if a
> > bug tracker had automatically logged them?
> 
> I am not assured of a reply, but surely the idea of a tracking system
> is that bugs don't get forgotten about. In my case, I would have
> raised an issue against xendomains, hopefully stated wants seems to go
> wrong and either it sits there and is dealt with, batted back to me
> for more info, or willfully ignored. But never should it just get
> "lost in the cracks".

Unfortunately without someone whose full time job it is to triage bugs
and keep the bug tracker under control all of the bugs which get batted
back and never followed up or which get ignored eventually overrun the
system and make it useless for anyone who would actually want to use it.
At this point you bug is just as likely to get lost in the mess as it is
to get lost on xen-devel.

> I'll shut up about it now, because whoever decides these things will
> do what they want, anyway.

We are working on a system which will allow us to record email threads
as being relevant and useful to track. We believe this will suit our
workflow better and avoid the need to have someone spend a lot of time
bug wrangling on the track.

This is why people are being encouraged to post their bugs to the list.

Ian.

Re: [Xen-users] xen forum

[Ian]

On 21/05/13 17:15, Ian Campbell wrote:
> The process (send a signed-off-by email to xen-devel) hasn't changed 
> in forever. Some of the tools which are convenient (but not required) 
> to use have changed recently and therefore some of the advice might 
> have changed. 

I probably misunderstood the necessity, in that case.

> FWIW the answer is that .gitignore is wrong and using -f would have 
> been fine if you couldn't see where .gitignore was wrong (and fixing 
> .gitignore would have been fine if you could see where). 

Okay, thanks.
>>> Why would you expect to be more assured of a reply to your mails if a
>>> bug tracker had automatically logged them?
>> I am not assured of a reply, but surely the idea of a tracking system
>> is that bugs don't get forgotten about. In my case, I would have
>> raised an issue against xendomains, hopefully stated wants seems to go
>> wrong and either it sits there and is dealt with, batted back to me
>> for more info, or willfully ignored. But never should it just get
>> "lost in the cracks".
> Unfortunately without someone whose full time job it is to triage bugs
> and keep the bug tracker under control all of the bugs which get batted
> back and never followed up or which get ignored eventually overrun the
> system and make it useless for anyone who would actually want to use it.
> At this point you bug is just as likely to get lost in the mess as it is
> to get lost on xen-devel.
>
>> I'll shut up about it now, because whoever decides these things will
>> do what they want, anyway.
> We are working on a system which will allow us to record email threads
> as being relevant and useful to track. We believe this will suit our
> workflow better and avoid the need to have someone spend a lot of time
> bug wrangling on the track.

Ok, fair enough. We'll see :)


> This is why people are being encouraged to post their bugs to the list.

In hindsight, I think in the case of my xl/xendomains issue, it is 
better investigated as a bug as although I have a working patch, I don't 
fully understand why it's not an issue for other people and also my 
paych is probably not compatible with xm. So I'll post a bug report to 
the list with my work-around and hopefully somebody who understands the 
subject matter better can unpick the issue in a more authoritative manner.

Thanks for your time,

Ian.


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

Re: [Xen-users] xen forum

[Konrad Rzeszutek Wilk]

On Tue, May 21, 2013 at 04:04:09PM +0100, Ian Murray wrote:
> 
> 
> >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.
> >
> 
> 
> My own experience is that posts (at least from me) are regularly missed/ignored on the devel list, including a signed patch, so I personally think a bug tracker would be a better option. Bug trackers don't (or at least shouldn't :) ) forget or miss. That's they're raison d'etre. I honestly don't know how anyone can do business using this list, but that's just my humble opinion.

Did you also look in the MAINTAINERS file to make sure you copied the right
maintainer?

The reason for skipping the Bugzilla system is that it is soo out of date that
we don't use it anymore.
> 
> As professional developer and application support bod myself, I wouldn't ask anybody to read that missive; I wouldn't get any bug reports ever!
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

Re: [Xen-users] xen forum

[jacek burghardt]

[-- Attachment #1.1: Type: text/plain, Size: 1485 bytes --]

What do you guys think about this bug reporting tool
http://www.thexenguy.com/bug


On Tue, May 21, 2013 at 10:31 AM, Konrad Rzeszutek Wilk <
konrad.wilk@oracle.com> wrote:

> On Tue, May 21, 2013 at 04:04:09PM +0100, Ian Murray wrote:
> >
> >
> > >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.htmlwhen
> > >doing it.
> > >
> >
> >
> > My own experience is that posts (at least from me) are regularly
> missed/ignored on the devel list, including a signed patch, so I personally
> think a bug tracker would be a better option. Bug trackers don't (or at
> least shouldn't :) ) forget or miss. That's they're raison d'etre. I
> honestly don't know how anyone can do business using this list, but that's
> just my humble opinion.
>
> Did you also look in the MAINTAINERS file to make sure you copied the right
> maintainer?
>
> The reason for skipping the Bugzilla system is that it is soo out of date
> that
> we don't use it anymore.
> >
> > As professional developer and application support bod myself, I wouldn't
> ask anybody to read that missive; I wouldn't get any bug reports ever!
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> >
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

[-- Attachment #1.2: Type: text/html, Size: 2379 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: [Xen-users] xen forum

[Ian]

> Did you also look in the MAINTAINERS file to make sure you copied the right
> maintainer?
I didn't copy anybody other than the devel list. I didn't know I was 
supposed to. Either I missed it or it wasn't on the submission instructions.




> The reason for skipping the Bugzilla system is that it is soo out of date that
> we don't use it anymore.

Shame.

Re: [Xen-users] xen forum

[Konrad Rzeszutek Wilk]

On Tue, May 21, 2013 at 12:31:02PM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, May 21, 2013 at 04:04:09PM +0100, Ian Murray wrote:
> > 
> > 
> > >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.
> > >
> > 
> > 
> > My own experience is that posts (at least from me) are regularly missed/ignored on the devel list, including a signed patch, so I personally think a bug tracker would be a better option. Bug trackers don't (or at least shouldn't :) ) forget or miss. That's they're raison d'etre. I honestly don't know how anyone can do business using this list, but that's just my humble opinion.
> 
> Did you also look in the MAINTAINERS file to make sure you copied the right
> maintainer?
> 
> The reason for skipping the Bugzilla system is that it is soo out of date that
> we don't use it anymore.


Actually I recall there is a secondary reason too - which is that we get copied
on distros bugs that affect Xen. For example in Fedora I (and Dariof) get copied on
any Linux kernel issues that are related to Xen. In Debian I believe Ian Campbell
gets copied as well. For SuSE it is Jan and Olaf. Not sure about the other distros.

And then if you use Oracle Linux, I get copied too. Then there is the internal bug system
if you using OVM and the Linux kernel bug-system where I get copied too.

That is a lot of bug systems to keep track of - and since most of the users use a 
distro they end up using their distro bug-system. And then Xen's bugzilla system 
became less and less important to keep track of stuff.

Oh, and there are the five mailing lists and the fire-hose LKML. Yuck, soo many emails.

Now I have to admit that everytime anybody reports an issue on xen-devel that regards
Linux I try to respond ASAP. Unfortunatly I miss it sometimes - and this Xen 4.3 release
overlapped with Linux v3.10 merge window (And my vacation) - so it was a triple whammy
when it came to keeping track of things. To keep track of things, and of all of those
different bug systems, and of what to get done for Xen or Linux I have a text file.

It is mostly FIFO with the 'oh wow, this needs to be fixed NOW!' preempting it.
In all honestly it sucks as a track system, but I am not really sure of how else to do this
without spending a massive time doing 'click here on this button and add this comment,
set dependency on this bug' and instead concentrate my time in an editor.

I believe we need something that can bridge both of these - helping developers to
know about bugs and also track them so users know that things are done and not ignored.
And so low maintaince for developers that they can focus on looking at code all day.

BTW, did I mention that Oracle is looking to hire Xen and Linux developers :-)
> > 
> > As professional developer and application support bod myself, I wouldn't ask anybody to read that missive; I wouldn't get any bug reports ever!
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> > 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

Re: [Xen-users] xen forum

[Gordan Bobic]

On 05/24/2013 03:04 PM, Konrad Rzeszutek Wilk wrote:

>>>> 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.
>>>>
>>>
>>>
>>> My own experience is that posts (at least from me) are regularly missed/ignored on the devel list, including a signed patch, so I personally think a bug tracker would be a better option. Bug trackers don't (or at least shouldn't :) ) forget or miss. That's they're raison d'etre. I honestly don't know how anyone can do business using this list, but that's just my humble opinion.
>>
>> Did you also look in the MAINTAINERS file to make sure you copied the right
>> maintainer?
>>
>> The reason for skipping the Bugzilla system is that it is soo out of date that
>> we don't use it anymore.
>
>
> Actually I recall there is a secondary reason too - which is that we get copied
> on distros bugs that affect Xen. For example in Fedora I (and Dariof) get copied on
> any Linux kernel issues that are related to Xen. In Debian I believe Ian Campbell
> gets copied as well. For SuSE it is Jan and Olaf. Not sure about the other distros.
>
> And then if you use Oracle Linux, I get copied too. Then there is the internal bug system
> if you using OVM and the Linux kernel bug-system where I get copied too.
>
> That is a lot of bug systems to keep track of - and since most of the users use a
> distro they end up using their distro bug-system. And then Xen's bugzilla system
> became less and less important to keep track of stuff.
>
> Oh, and there are the five mailing lists and the fire-hose LKML. Yuck, soo many emails.

Surely the sensible thing to do is to have one Xen bug tracking system 
and only use that. If distro maintainers wish to file bugs in the Xen 
bug tracker for Xen bugs, they are free to do so, same as any other 
user. Xen is the upstream project - Xen bugs should be fed from distros 
up to Xen, not the other way around. Xen bugs are then tracked with the 
single Xen bug tracker and they are all in one place, searchable 
reviewable and easy to keep track of. Is this not obvious? Am I missing 
missing an issue that has been too-subtly implied but not explicitly stated?

> Now I have to admit that everytime anybody reports an issue on xen-devel that regards
> Linux I try to respond ASAP. Unfortunatly I miss it sometimes  - and this Xen 4.3 release
> overlapped with Linux v3.10 merge window (And my vacation) - so it was a triple whammy
> when it came to keeping track of things. To keep track of things, and of all of those
> different bug systems, and of what to get done for Xen or Linux I have a text file.

I don't understand why it would be in any way shape or form the 
responsibility of any Xen developer to look at any bug tracking system 
other than Xen's specific one for Xen bugs. Distro maintainers escalate 
bugs from their bug tracking systems to Xen's. If/when the bug gets 
fixed in Xen and the ticket is updated accordingly in Xen's bug tracking 
system, it is thereafter the distro maintainers responsibility to notice 
this and feed it back down into the distro.

> It is mostly FIFO with the 'oh wow, this needs to be fixed NOW!' preempting it.
> In all honestly it sucks as a track system, but I am not really sure of how else to do this
> without spending a massive time doing 'click here on this button and add this comment,
> set dependency on this bug' and instead concentrate my time in an editor.
>
> I believe we need something that can bridge both of these - helping developers to
> know about bugs and also track them so users know that things are done and not ignored.
> And so low maintaince for developers that they can focus on looking at code all day.

I don't think this is a new problem, and I do think the problem has been 
solved many times and solved well. If there is an obvious flaw in what I 
said above, please do point it out. But claiming that a broadcast system 
is bad and therefore ignoring a single-point tracking system is the way 
forward is as much of a contradiction in terms as I can imagine on this 
subject.

Gordan

Re: [Xen-users] xen forum

[Stefano Stabellini]

On Fri, 24 May 2013, Gordan Bobic wrote:
> On 05/24/2013 03:04 PM, Konrad Rzeszutek Wilk wrote:
> 
> > > > > 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.
> > > > > 
> > > > 
> > > > 
> > > > My own experience is that posts (at least from me) are regularly
> > > > missed/ignored on the devel list, including a signed patch, so I
> > > > personally think a bug tracker would be a better option. Bug trackers
> > > > don't (or at least shouldn't :) ) forget or miss. That's they're raison
> > > > d'etre. I honestly don't know how anyone can do business using this
> > > > list, but that's just my humble opinion.
> > > 
> > > Did you also look in the MAINTAINERS file to make sure you copied the
> > > right
> > > maintainer?
> > > 
> > > The reason for skipping the Bugzilla system is that it is soo out of date
> > > that
> > > we don't use it anymore.
> > 
> > 
> > Actually I recall there is a secondary reason too - which is that we get
> > copied
> > on distros bugs that affect Xen. For example in Fedora I (and Dariof) get
> > copied on
> > any Linux kernel issues that are related to Xen. In Debian I believe Ian
> > Campbell
> > gets copied as well. For SuSE it is Jan and Olaf. Not sure about the other
> > distros.
> > 
> > And then if you use Oracle Linux, I get copied too. Then there is the
> > internal bug system
> > if you using OVM and the Linux kernel bug-system where I get copied too.
> > 
> > That is a lot of bug systems to keep track of - and since most of the users
> > use a
> > distro they end up using their distro bug-system. And then Xen's bugzilla
> > system
> > became less and less important to keep track of stuff.
> > 
> > Oh, and there are the five mailing lists and the fire-hose LKML. Yuck, soo
> > many emails.
> 
> Surely the sensible thing to do is to have one Xen bug tracking system and
> only use that. If distro maintainers wish to file bugs in the Xen bug tracker
> for Xen bugs, they are free to do so, same as any other user. Xen is the
> upstream project - Xen bugs should be fed from distros up to Xen, not the
> other way around. Xen bugs are then tracked with the single Xen bug tracker
> and they are all in one place, searchable reviewable and easy to keep track
> of. Is this not obvious? Am I missing missing an issue that has been
> too-subtly implied but not explicitly stated?

In an ideal world maybe. What usually happens is that distros keep using
their bug trackers and keep recommending their users to fill bug to
them. These bug trackers get out of sync with the upstream bug tracker.
Moreover some people don't use bug trackers and submit bugs as emails
anyway, as a consequence the bug tracker usually needs to be kept
up-to-date manually by one or more members of the community. In the long
run they tend to be "left behind".
In Linux it has been tried several times to introduce bug trackers,
most of the times failing completely.


 
> > It is mostly FIFO with the 'oh wow, this needs to be fixed NOW!' preempting
> > it.
> > In all honestly it sucks as a track system, but I am not really sure of how
> > else to do this
> > without spending a massive time doing 'click here on this button and add
> > this comment,
> > set dependency on this bug' and instead concentrate my time in an editor.
> > 
> > I believe we need something that can bridge both of these - helping
> > developers to
> > know about bugs and also track them so users know that things are done and
> > not ignored.
> > And so low maintaince for developers that they can focus on looking at code
> > all day.
> 
> I don't think this is a new problem, and I do think the problem has been
> solved many times and solved well. If there is an obvious flaw in what I said
> above, please do point it out. But claiming that a broadcast system is bad and
> therefore ignoring a single-point tracking system is the way forward is as
> much of a contradiction in terms as I can imagine on this subject.
 
It is not a new problem but it has never been solved properly, just give
a look at the status of bug trackers in the linux kernel to get an idea.
Lunchpad was supposed to be the bug tracker to rule them all, but it
ended up being just one more bug tracker.

That said, I don't mean that it's all hopeless and doomed, you certainly
raised some good points and I think we have room for improvement.
It's just not as simple as it seems.
Personally I am in favor of introducing a bug tracker if we have a way
to integrate it into our current process and make sure it's kept up to
date.

Re: [Xen-users] xen forum

[Gordan Bobic]

On 05/24/2013 10:36 PM, Stefano Stabellini wrote:

>>>>>> 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.
>>>>>>
>>>>>
>>>>>
>>>>> My own experience is that posts (at least from me) are regularly
>>>>> missed/ignored on the devel list, including a signed patch, so I
>>>>> personally think a bug tracker would be a better option. Bug trackers
>>>>> don't (or at least shouldn't :) ) forget or miss. That's they're raison
>>>>> d'etre. I honestly don't know how anyone can do business using this
>>>>> list, but that's just my humble opinion.
>>>>
>>>> Did you also look in the MAINTAINERS file to make sure you copied the
>>>> right
>>>> maintainer?
>>>>
>>>> The reason for skipping the Bugzilla system is that it is soo out of date
>>>> that
>>>> we don't use it anymore.
>>>
>>>
>>> Actually I recall there is a secondary reason too - which is that we get
>>> copied
>>> on distros bugs that affect Xen. For example in Fedora I (and Dariof) get
>>> copied on
>>> any Linux kernel issues that are related to Xen. In Debian I believe Ian
>>> Campbell
>>> gets copied as well. For SuSE it is Jan and Olaf. Not sure about the other
>>> distros.
>>>
>>> And then if you use Oracle Linux, I get copied too. Then there is the
>>> internal bug system
>>> if you using OVM and the Linux kernel bug-system where I get copied too.
>>>
>>> That is a lot of bug systems to keep track of - and since most of the users
>>> use a
>>> distro they end up using their distro bug-system. And then Xen's bugzilla
>>> system
>>> became less and less important to keep track of stuff.
>>>
>>> Oh, and there are the five mailing lists and the fire-hose LKML. Yuck, soo
>>> many emails.
>>
>> Surely the sensible thing to do is to have one Xen bug tracking system and
>> only use that. If distro maintainers wish to file bugs in the Xen bug tracker
>> for Xen bugs, they are free to do so, same as any other user. Xen is the
>> upstream project - Xen bugs should be fed from distros up to Xen, not the
>> other way around. Xen bugs are then tracked with the single Xen bug tracker
>> and they are all in one place, searchable reviewable and easy to keep track
>> of. Is this not obvious? Am I missing missing an issue that has been
>> too-subtly implied but not explicitly stated?
>
> In an ideal world maybe. What usually happens is that distros keep using
> their bug trackers and keep recommending their users to fill bug to
> them. These bug trackers get out of sync with the upstream bug tracker.

That's distro problem, not a Xen problem, and should not be expected to 
be a Xen problem, nor should it ever become a Xen problem.

> Moreover some people don't use bug trackers and submit bugs as emails
> anyway, as a consequence the bug tracker usually needs to be kept
> up-to-date manually by one or more members of the community.

So stop accepting emailed bug reports. If somebody emails one, tell them 
to create a bugzilla account and file it there. If that is too hard, 
they clearly don't care about the bug enough. It's no better or worse a 
filtering system than seeing who is going to bother bumping an email 
thread if it gets missed.

> In the long run they tend to be "left behind".
> In Linux it has been tried several times to introduce bug trackers,
> most of the times failing completely.

My preferred Linux distribution uses a bugzilla bug tracker and it works 
very well indeed.

>>> It is mostly FIFO with the 'oh wow, this needs to be fixed NOW!' preempting
>>> it.
>>> In all honestly it sucks as a track system, but I am not really sure of how
>>> else to do this
>>> without spending a massive time doing 'click here on this button and add
>>> this comment,
>>> set dependency on this bug' and instead concentrate my time in an editor.
>>>
>>> I believe we need something that can bridge both of these - helping
>>> developers to
>>> know about bugs and also track them so users know that things are done and
>>> not ignored.
>>> And so low maintaince for developers that they can focus on looking at code
>>> all day.
>>
>> I don't think this is a new problem, and I do think the problem has been
>> solved many times and solved well. If there is an obvious flaw in what I said
>> above, please do point it out. But claiming that a broadcast system is bad and
>> therefore ignoring a single-point tracking system is the way forward is as
>> much of a contradiction in terms as I can imagine on this subject.
>
> It is not a new problem but it has never been solved properly, just give
> a look at the status of bug trackers in the linux kernel to get an idea.
> Lunchpad was supposed to be the bug tracker to rule them all, but it
> ended up being just one more bug tracker.

It works just fine for RH and Fedora. So clearly the problem must be in 
something else.

> That said, I don't mean that it's all hopeless and doomed, you certainly
> raised some good points and I think we have room for improvement.
> It's just not as simple as it seems.
> Personally I am in favor of introducing a bug tracker if we have a way
> to integrate it into our current process and make sure it's kept up to
> date.

I sincerely hope it happens.

Gordan

Re: [Xen-users] xen forum

[Konrad Rzeszutek Wilk]

> >>too-subtly implied but not explicitly stated?
> >
> >In an ideal world maybe. What usually happens is that distros keep using
> >their bug trackers and keep recommending their users to fill bug to
> >them. These bug trackers get out of sync with the upstream bug tracker.
> 
> That's distro problem, not a Xen problem, and should not be expected
> to be a Xen problem, nor should it ever become a Xen problem.

There are two coins of this - one of helping distros with their bugs
and then the second which is to help Xen community users who don't
use the distro bugs. The first is solved by distros bug system, the
second is well, not solved. I think at the bottom of this particular
email a potential solution has been identified?

> 
> >Moreover some people don't use bug trackers and submit bugs as emails
> >anyway, as a consequence the bug tracker usually needs to be kept
> >up-to-date manually by one or more members of the community.
> 
> So stop accepting emailed bug reports. If somebody emails one, tell
> them to create a bugzilla account and file it there. If that is too
> hard, they clearly don't care about the bug enough. It's no better
> or worse a filtering system than seeing who is going to bother
> bumping an email thread if it gets missed.

The issue (at least as I see it), is not emailed bug reports.

Those are actually easier for me to digest.

> 
> >In the long run they tend to be "left behind".
> >In Linux it has been tried several times to introduce bug trackers,
> >most of the times failing completely.
> 
> My preferred Linux distribution uses a bugzilla bug tracker and it
> works very well indeed.

Right, I think you are saying you agree that this model works best for users?
> 
> >>>It is mostly FIFO with the 'oh wow, this needs to be fixed NOW!' preempting
> >>>it.
> >>>In all honestly it sucks as a track system, but I am not really sure of how
> >>>else to do this
> >>>without spending a massive time doing 'click here on this button and add
> >>>this comment,
> >>>set dependency on this bug' and instead concentrate my time in an editor.
> >>>
> >>>I believe we need something that can bridge both of these - helping
> >>>developers to
> >>>know about bugs and also track them so users know that things are done and
> >>>not ignored.
> >>>And so low maintaince for developers that they can focus on looking at code
> >>>all day.
> >>
> >>I don't think this is a new problem, and I do think the problem has been
> >>solved many times and solved well. If there is an obvious flaw in what I said
> >>above, please do point it out. But claiming that a broadcast system is bad and
> >>therefore ignoring a single-point tracking system is the way forward is as
> >>much of a contradiction in terms as I can imagine on this subject.
> >
> >It is not a new problem but it has never been solved properly, just give
> >a look at the status of bug trackers in the linux kernel to get an idea.
> >Lunchpad was supposed to be the bug tracker to rule them all, but it
> >ended up being just one more bug tracker.
> 
> It works just fine for RH and Fedora. So clearly the problem must be
> in something else.

Bugs in RH and Fedora system are not mirrored in the respective community
bug systems.

Meaning that the engineers who work there don't have the time to mirror
their user's bugs in whatever community they are involved. Some of them
do but some of them just point to the Red Hat or Fedora bugs and ask
the community to help with this.

> 
> >That said, I don't mean that it's all hopeless and doomed, you certainly
> >raised some good points and I think we have room for improvement.
> >It's just not as simple as it seems.
> >Personally I am in favor of introducing a bug tracker if we have a way
> >to integrate it into our current process and make sure it's kept up to
> >date.
> 
> I sincerely hope it happens.
> 
> Gordan

Re: [Xen-users] xen forum

[George Dunlap]

On Fri, May 24, 2013 at 11:14 PM, Gordan Bobic <gordan@bobich.net> wrote:
> So stop accepting emailed bug reports. If somebody emails one, tell them to
> create a bugzilla account and file it there. If that is too hard, they
> clearly don't care about the bug enough. It's no better or worse a filtering
> system than seeing who is going to bother bumping an email thread if it gets
> missed.

OK, seriously dude -- who are you to come around here and tell us how
to run things?

You are not a developer in our project, and you do not know what it's
like to develop Xen.  You are therefore not in a position to be
telling us what the best solution is for us

We do appreciate having the user perspective, so thank you for sharing
with you your opinion on the e-mail bug reporting.  We will take it
into consideration as we move forward.

 -George

Re: [Xen-users] xen forum

[Andrew Bobulsky]

[-- Attachment #1.1: Type: text/plain, Size: 6885 bytes --]

Hello Konrad, and others at Oracle,

On Fri, May 24, 2013 at 10:04 AM, Konrad Rzeszutek Wilk <
konrad.wilk@oracle.com> wrote:

> On Tue, May 21, 2013 at 12:31:02PM -0400, Konrad Rzeszutek Wilk wrote:
> > On Tue, May 21, 2013 at 04:04:09PM +0100, Ian Murray wrote:
> > >
> > >
> > > >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.htmlwhen
> > > >doing it.
> > > >
> > >
> > >
> > > My own experience is that posts (at least from me) are regularly
> missed/ignored on the devel list, including a signed patch, so I personally
> think a bug tracker would be a better option. Bug trackers don't (or at
> least shouldn't :) ) forget or miss. That's they're raison d'etre. I
> honestly don't know how anyone can do business using this list, but that's
> just my humble opinion.
> >
> > Did you also look in the MAINTAINERS file to make sure you copied the
> right
> > maintainer?
> >
> > The reason for skipping the Bugzilla system is that it is soo out of
> date that
> > we don't use it anymore.
>
>
> Actually I recall there is a secondary reason too - which is that we get
> copied
> on distros bugs that affect Xen. For example in Fedora I (and Dariof) get
> copied on
> any Linux kernel issues that are related to Xen. In Debian I believe Ian
> Campbell
> gets copied as well. For SuSE it is Jan and Olaf. Not sure about the other
> distros.
>
> And then if you use Oracle Linux, I get copied too. Then there is the
> internal bug system
> if you using OVM and the Linux kernel bug-system where I get copied too.
>
> That is a lot of bug systems to keep track of - and since most of the
> users use a
> distro they end up using their distro bug-system. And then Xen's bugzilla
> system
> became less and less important to keep track of stuff.
>
> Oh, and there are the five mailing lists and the fire-hose LKML. Yuck, soo
> many emails.
>
> Now I have to admit that everytime anybody reports an issue on xen-devel
> that regards
> Linux I try to respond ASAP. Unfortunatly I miss it sometimes - and this
> Xen 4.3 release
> overlapped with Linux v3.10 merge window (And my vacation) - so it was a
> triple whammy
> when it came to keeping track of things. To keep track of things, and of
> all of those
> different bug systems, and of what to get done for Xen or Linux I have a
> text file.
>
> It is mostly FIFO with the 'oh wow, this needs to be fixed NOW!'
> preempting it.
> In all honestly it sucks as a track system, but I am not really sure of
> how else to do this
> without spending a massive time doing 'click here on this button and add
> this comment,
> set dependency on this bug' and instead concentrate my time in an editor.
>
> I believe we need something that can bridge both of these - helping
> developers to
> know about bugs and also track them so users know that things are done and
> not ignored.
> And so low maintaince for developers that they can focus on looking at
> code all day.
>

You bring up what seems to me is an obvious point: If developers are
busy... developing... Why should they sacrifice time spent focusing on any
given issue to 1) prioritize which issues should be the responsibility of
an individual developer, and 2) assigning weight to these issues based on
each of your own arbitrary sets of skills, requirements, etc?  If I
understand the principles of open source projects (and I admit: I may
not!), such responsibility usually falls on the project leader[s].  Xen,
however, is just seemingly so damn big that it's nearly impossible to
consolidate everything to the point where these decisions can be made,
especially with regard to bug tracking and fixing.  At least that's the
sense I'm getting as I've followed this thread for the last week or so ;-)

Your suggestion, Konrad, of something that will bridge the gap---regardless
of whether that gap really stems from an issue of size and scope as I
suggest, or even if I'm off base, just so long as the real issue is similar
enough---is definitely what I, too, suspect is needed.

Out of all the solutions that exist---and I lost count of the number of
pieces of software that have been mentioned in this thread---it's painfully
obvious that the search for the "Silver Bullet" has been an unfortunate
failure up to this point.  While I'm loathe to say it, especially since
solving problems with software is a solution we all love and respect, the
only thing I've been able to think of that *will *fill the void and bridge
that gap is relatively simple, but far from easy: a human touch.

Pick the bug tracking system that the developers want to work with, and
then have someone whose sole responsibility is to keep it neat, organized,
and summarized.  As bugs reach certain threshholds, the bug list curator
can nudge a developer for an update, and even if the curator doesn't get
one, at least information can be compiled and "attacked" from the other
direction. In this fashion, at least if a developer goes AWOL on a bug
because it's low priority or deprecated code or whatnot, all he has to do
is answer an email and the rest of the filing and tracking duties are taken
care of by someone else.  And if there's anything that I'm getting from
this thread, it's a sense that keeping things as simple as email without
having to wade through the sometimes mind-boggling volume of email on the
Xen-Devel list is the only thing on which a large number of people seem to
agree.... myself included ;-)

---

I've come back to the Xen project over and over again because it really is
some terrific software.  The more I think about it, the more I see a world
in which the future of *all* computing takes place on top of Xen and Linux,
as the combination of the two come ever closer to blurring the lines
between firmware and OS.  One day I expect that I'll stop syncing data from
one place to the next and it'll all just live on Amazon or at my house, and
I'll use the same operating system---the exact same instance---on every
device.  It's an exciting time to be a nerd ;-)

BTW, did I mention that Oracle is looking to hire Xen and Linux developers
> :-)
>

Any chance that the full-time position I mention above is one of them? :-D

Best Regards,
Andrew Bobulsky

> >
> > > As professional developer and application support bod myself, I
> wouldn't ask anybody to read that missive; I wouldn't get any bug reports
> ever!
> > >
> > >
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xen.org
> > > http://lists.xen.org/xen-devel
> > >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> >
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

[-- Attachment #1.2: Type: text/html, Size: 8554 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: [Xen-users] xen forum

[Konrad Rzeszutek Wilk]

> > I believe we need something that can bridge both of these - helping
> > developers to
> > know about bugs and also track them so users know that things are done and
> > not ignored.
> > And so low maintaince for developers that they can focus on looking at
> > code all day.
> >
> 
> You bring up what seems to me is an obvious point: If developers are
> busy... developing... Why should they sacrifice time spent focusing on any
> given issue to 1) prioritize which issues should be the responsibility of
> an individual developer, and 2) assigning weight to these issues based on
> each of your own arbitrary sets of skills, requirements, etc?  If I
> understand the principles of open source projects (and I admit: I may
> not!), such responsibility usually falls on the project leader[s].  Xen,
> however, is just seemingly so damn big that it's nearly impossible to
> consolidate everything to the point where these decisions can be made,
> especially with regard to bug tracking and fixing.  At least that's the
> sense I'm getting as I've followed this thread for the last week or so ;-)

And there sub-projects - hypervisor, tools (libxc, libxl, xenstore, xend,
xenctx, ..,) QEMU,  Linux kernel
> 
> Your suggestion, Konrad, of something that will bridge the gap---regardless
> of whether that gap really stems from an issue of size and scope as I
> suggest, or even if I'm off base, just so long as the real issue is similar
> enough---is definitely what I, too, suspect is needed.
> 
> Out of all the solutions that exist---and I lost count of the number of
> pieces of software that have been mentioned in this thread---it's painfully
> obvious that the search for the "Silver Bullet" has been an unfortunate
> failure up to this point.  While I'm loathe to say it, especially since
> solving problems with software is a solution we all love and respect, the
> only thing I've been able to think of that *will *fill the void and bridge
> that gap is relatively simple, but far from easy: a human touch.
> 
> Pick the bug tracking system that the developers want to work with, and
> then have someone whose sole responsibility is to keep it neat, organized,
> and summarized.  As bugs reach certain threshholds, the bug list curator
> can nudge a developer for an update, and even if the curator doesn't get
> one, at least information can be compiled and "attacked" from the other
> direction. In this fashion, at least if a developer goes AWOL on a bug
> because it's low priority or deprecated code or whatnot, all he has to do
> is answer an email and the rest of the filing and tracking duties are taken
> care of by someone else.  And if there's anything that I'm getting from
> this thread, it's a sense that keeping things as simple as email without
> having to wade through the sometimes mind-boggling volume of email on the
> Xen-Devel list is the only thing on which a large number of people seem to
> agree.... myself included ;-)

This release George Dunlap volunteered to be a release manager which meant
that his job was to track the features and bugs that he was aware of.
And to remind people about the deadlines.

It helped a lot (at least from my view) with making sure I had X, Y, and
Z ready by a certain data.
> 
> ---
> 
> I've come back to the Xen project over and over again because it really is
> some terrific software.  The more I think about it, the more I see a world
> in which the future of *all* computing takes place on top of Xen and Linux,
> as the combination of the two come ever closer to blurring the lines
> between firmware and OS.  One day I expect that I'll stop syncing data from
> one place to the next and it'll all just live on Amazon or at my house, and
> I'll use the same operating system---the exact same instance---on every
> device.  It's an exciting time to be a nerd ;-)

/me laughs. It certainly is!
> 
> BTW, did I mention that Oracle is looking to hire Xen and Linux developers
> > :-)
> >
> 
> Any chance that the full-time position I mention above is one of them? :-D

Our group is looking at engineers that are comfortable working on the Linux
kernel and Xen to make them both better and faster.

I will find out if there are other groups within Oracle who are looking
for a release manager type person that is more focused on the "human touch"
part :-)

> 
> Best Regards,
> Andrew Bobulsky
> 
> > >
> > > > As professional developer and application support bod myself, I
> > wouldn't ask anybody to read that missive; I wouldn't get any bug reports
> > ever!
> > > >
> > > >
> > > > _______________________________________________
> > > > Xen-devel mailing list
> > > > Xen-devel@lists.xen.org
> > > > http://lists.xen.org/xen-devel
> > > >
> > >
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xen.org
> > > http://lists.xen.org/xen-devel
> > >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> >

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