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 _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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 >
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 >
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
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
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 > > >
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 > > >
May be you are correct but i believe that the volume of emails makes difficult to find info you looking for. Forum you can post stickies and users can help each other fix bugs. If user a states that they have this issue with xen and user b had same issue and found a patch and posts info about it that will make easy for rest of user to download and install patch. It very hard to search mailing list. xen vga pass info is interesting also there lots of info about and many patches but main website with patches is down. I posted patches for xen 4.3 i hope somone can provide patches for xen 4.2 On Sun, May 19, 2013 at 11:14 AM, Gordan Bobic <gordan@bobich.net> wrote:> On 05/19/2013 04:24 PM, jacek burghardt wrote: > >> I want to add bug tracking software but forum seems like great place to >> ask questions and exchange ideas. I am open to people willing to be >> moderators and ideas for sections of board. I have horrible time >> searching mailing lists. How many times we have people asking >> on reassigning video cards sound cards. I believe having one place for >> related bios files patches and howtos will be very nice. >> > > That sounds like something that should be on the wiki, not on a forum. And > there already is a wiki. It might be under-maintained, but it does exist. > So is the solution really yet more sources of information or more/better > use of the sources that are already there? > > I am all for raising the profile of the issue and getting the community > more involved, which is what I figure you''re trying to do. Having said > that, the problem is that we don''t seem to be getting as much traction from > the developers and other people more familiar with the internals of Xen. > > I can understand that the developers on a project like this are generally > going to be coming from two separate camps: > > 1) People who became developers to fix the problems they were having and > have limited interest in other bugs other people are hitting. > > 2) People who are paid to do development by their employer, who are only > going to be focusing on any issues that arise on a very limited selection > of hardware/OS/software combinations that are deemed "supported" by their > employer, and generally won''t care about any other issues, especially those > that don''t manifest on the "supported" hardware. > > This explains why a lot of questions go unanswered even though they refer > to bugs that were filed on the xensource bugzilla years ago. > > > I see people >> ask questions on this mailing board and get no answers does it get >> missed or it was asked before I don''t know but I believe having a forum >> maybe the answer to it. >> > > I wish you were right, but I cannot see any reason why a forum might get > more traction than a mailing list. Mailing lists get posts straight to your > inbox where people who know the answer are more likely to hear them. On the > forum they are only going to get spotted by the people who actively look at > the forum, and those are generally going to be the ones looking for > solutions to their own problems rather than the developers who might > actually be able to resolve an issue. > > Gordan >_______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
Hi all, I wanted to step in here and give some extra context, as in fact some of this has been discussed at last week''s Hackathon and also before. The thread is mixing a few different questions: a) A better place for user questions than mail: aka the forum vs. mail discussion b) How to better track bugs (including the role of http://bugzilla.xensource.com/**bugzilla/<http://bugzilla.xensource.com/bugzilla/> ) c) The specific state of patches for for Xen patches - that should be discussed elsewhere On a): As part of the new xenproject.org website we created http://xenproject.org/help/questions-and-answers.html Right now xenproject.org is in beta, and we are resolving some issues with sign-up (a sizable proportion of new site members never get their activation mails). We decided to go for a stackoverflow like Q&A system with tags, instead of a forum. That should make user questions more easily searchable due to the extra structure that Q&A systems provide and the tagging. You just need to start using it. I was first thinking of migrating content to the new system, but we have too much historical data and it would not benefit from the tagging. However, this system is not intended for bugs. On b): Exactly the question of bugs, bugs getting lost and bug trackers was discussed at some length at the Xen Hackathon last week. The official policy is http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen and has been for years. Doing bugs this way, puts a burden on the user to keep on top of their bugs (and re-send after a few months if it is sitting there). The assumption is that if you don''t do this "your bug is not important enough". Now, I raised the issue of tracking bugs better with the Xen developers many times. As it turns out in the Xen dev community the VAST majority of maintainers prefer bugs to be raised via the dev list. In contrast in the kernel dev community both raising bugs via the dev list and bugzilla.kernel.org are official: you have to know which maintainer prefers which mechanism - if you don''t know and use the wrong one, your bug is simpply ignored. Anyway, Ian Campbell developed an e-mail based bug tracking system which is being trialed in the Xen community right now. I can''t find the mail thread for it (I am suffering from not being able to find what I know is there). But the basic principle is that by adding a special e-mail address to a thread, means the bug gets tracked and that there is a simple web interface that creates lists of bugs (and conversations around them). There is also a simple (e-mail) way to mark bugs as closed. That creates some new opportunities, but also challenges for the dev community which have to be resolved. I wrote down notes re the Hackathon discussion, but am waiting for additional notes from others, which I will post later this week on xen-devel.> I''m guessing there is no longer a relevant bugzilla, then? http://bugzilla.xensource.com/**bugzilla/ <http://bugzilla.xensource.com/bugzilla/>This system was never really the official Xen bug-tracker (or has not been for a very long time). It was created for one large vendors in the contributor community which needed a bug tracker for their internal purposes. Which is why we do not promote bugzilla. Typically, that vendor will keep bugs in bugzilla but also send to xen-devel. I just played with this, and we have an SEO issue: - if you search for "xen bugs" you get to the right page (aka http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen) - if you search for "xen bugzilla" you get to http://bugzilla.xensource.com/bugzilla/ (that is fine, but the bugzilla doesn''t tell you NOT to use it and does not point you to http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen) This creates confusion. I will look into this and see what can be done. Regards Lars On Sun, May 19, 2013 at 6:56 PM, jacek burghardt <jaceksburghardt@gmail.com>wrote:> May be you are correct but i believe that the volume of emails makes > difficult to find info you looking for. Forum you can post stickies and > users can help each other fix bugs. If user a states that they have this > issue with xen and user b had same issue and found a patch and posts info > about it that will make easy for rest of user to download and install > patch. It very hard to search mailing list. xen vga pass info is > interesting also there lots of info about and many patches but main website > with patches is down. I posted patches for xen 4.3 i hope somone can > provide patches for xen 4.2 >_______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
I just got permanent domain www.thexenguy.com/forums _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
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 joinIt 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.
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 joinIt 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.
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
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
>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!
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.
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.
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.
>> 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. >
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.
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 >
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 >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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
> 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.
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
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
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
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
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 > missingThe 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.
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 > missingThe 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.
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
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
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
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
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.comSomebody 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
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.comSomebody 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
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
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
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
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
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
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
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.
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.
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
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
I know that is impossible to use qemu git with Xen 4.3 I can start hvm but pvm gives me invalid ICC bridge value qemu added ICC in _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
On Wed, 2013-05-22 at 10:07 -0600, jacek burghardt wrote:> I know that is impossible to use qemu git with Xen 4.3 I can start hvm > but pvm gives me invalid ICC bridge value qemu added ICC inPlease file a proper report on xen-devel according to: http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen Thanks. Ian.
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
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
I will file bug report I belive the issue is related to this patch in qemu git. I hope that somone could point me were xen code is for pvm that interacts with qemu it seems to fix it would change/ add some definitions in code. http://lists.gnu.org/archive/html/qemu-devel/2013-04/msg05787.html On Wed, May 22, 2013 at 10:07 AM, jacek burghardt <jaceksburghardt@gmail.com> wrote:> I know that is impossible to use qemu git with Xen 4.3 I can start hvm but > pvm gives me invalid ICC bridge value qemu added ICC in >_______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
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
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
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
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
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
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
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.
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.
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
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
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
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
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 >
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
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.
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
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 >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
> >>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
> > 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? :-DOur 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
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
Maybe Matching Threads
- xen forum
- [PATCH] fix XSA-46 regression with xend/xm
- Is my Intel HD Graphics 4600 Xen VGA Passthrough to Windows 8 Enterprise HVM domU Considered Successful?
- Is my Intel HD Graphics 4600 Xen VGA Passthrough to Windows 8 Enterprise HVM domU Considered Successful?
- GeForce 4xx/Fermi to Quadro Modifying Quide