From: Gordan Bobic <gordan@bobich.net>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Ian Murray <murrayie@yahoo.co.uk>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-users] xen forum
Date: Fri, 24 May 2013 20:37:58 +0100 [thread overview]
Message-ID: <519FC196.4090506@bobich.net> (raw)
In-Reply-To: <20130524140402.GA3750@phenom.dumpdata.com>
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
next prev parent reply other threads:[~2013-05-24 19:37 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-19 15:09 xen forum jacek burghardt
2013-05-19 15:16 ` Gordan Bobic
2013-05-19 16:36 ` Joseph Glanville
2013-05-19 17:04 ` Gordan Bobic
2013-05-21 14:29 ` Konrad Rzeszutek Wilk
2013-05-21 14:57 ` Gordan Bobic
2013-05-21 15:04 ` [Xen-users] " Ian Campbell
2013-05-22 6:18 ` Bartek Krawczyk
[not found] ` <CAFp_H4vqFyNN-ZPTo-C2rN6_j1DsXWWPugNM8du9Ssa+V1FHAQ@mail.gmail.com>
2013-05-22 6:55 ` Gordan Bobic
2013-05-22 9:53 ` Ian Campbell
2013-05-22 9:58 ` George Dunlap
2013-05-22 15:27 ` Gordan Bobic
2013-05-22 15:32 ` George Dunlap
2013-05-22 15:52 ` Gordan Bobic
2013-05-22 15:53 ` Ian Campbell
2013-05-22 15:58 ` George Dunlap
2013-05-22 20:54 ` Gordan Bobic
2013-05-23 10:41 ` George Dunlap
2013-05-23 12:04 ` Ian Campbell
2013-05-23 13:08 ` George Dunlap
2013-05-22 10:20 ` George Dunlap
2013-05-22 15:24 ` Gordan Bobic
2013-05-22 16:18 ` George Dunlap
2013-05-22 16:44 ` Gordan Bobic
2013-05-23 13:40 ` George Dunlap
2013-05-21 15:04 ` Ian Murray
2013-05-21 15:19 ` Ian Campbell
2013-05-21 16:00 ` Ian Murray
2013-05-21 16:15 ` Ian Campbell
2013-05-21 17:57 ` Ian
2013-05-21 16:31 ` Konrad Rzeszutek Wilk
2013-05-21 17:19 ` jacek burghardt
2013-05-21 18:03 ` Ian
2013-05-24 14:04 ` Konrad Rzeszutek Wilk
2013-05-24 19:37 ` Gordan Bobic [this message]
2013-05-24 21:36 ` Stefano Stabellini
2013-05-24 22:14 ` Gordan Bobic
2013-05-25 12:06 ` Konrad Rzeszutek Wilk
2013-05-28 16:00 ` George Dunlap
2013-05-25 3:07 ` Andrew Bobulsky
2013-05-28 13:49 ` Konrad Rzeszutek Wilk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=519FC196.4090506@bobich.net \
--to=gordan@bobich.net \
--cc=konrad.wilk@oracle.com \
--cc=murrayie@yahoo.co.uk \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.