From: Gordan Bobic <gordan@bobich.net>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Murray <murrayie@yahoo.co.uk>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-users] xen forum
Date: Fri, 24 May 2013 23:14:18 +0100 [thread overview]
Message-ID: <519FE63A.6070001@bobich.net> (raw)
In-Reply-To: <alpine.DEB.2.02.1305242226140.4799@kaball.uk.xensource.com>
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
next prev parent reply other threads:[~2013-05-24 22:14 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
2013-05-24 21:36 ` Stefano Stabellini
2013-05-24 22:14 ` Gordan Bobic [this message]
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=519FE63A.6070001@bobich.net \
--to=gordan@bobich.net \
--cc=konrad.wilk@oracle.com \
--cc=murrayie@yahoo.co.uk \
--cc=stefano.stabellini@eu.citrix.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).