[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.