<div dir="ltr">Hi<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 14, 2014 at 4:51 PM, Ian Malone <span dir="ltr"></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>On the other hand the casual bug reporter can't be expected to be able to determine that their bug is an upstream one, so if the package maintainer or triager is able to look at a bug and say, "this is an upstream issue", then click a button to connect it upwards that would stop this being a problem.<br>
</div></div></div></div></blockquote><div> <br></div><div><br></div><div>Sure, that has been suggested many times before but it isn't easy to achieve that. For one, we don't really have any active triaging team and package maintainers have to do that triaging as well typically but the more important problem is that, bugzilla is not a universal tracking system (think launchpad, <a href="http://sf.net">sf.net</a>, google code tracker, github, projects using trac, redmine etc etc) and even within bugzilla many instances are very heavily customized to suit project specific workflows so trying to establish a connection to an upstream project (authentication and authorization) and finding a good way to map the information from distro speciifc bug tracker to the upstream project bug tracker and keeping track of the status etc automatically isn't an easy problem at all. <br>
<br>Launchpad tried to do some of this but it has failed to achieve that vision partly because it was proprietary for a long time and even now doesn't work like a regular open source project (no releases etc) and is tied to bzr version control which not many want to use.<br>
<br></div><div>Rahul<br></div></div></div></div></div>