What do we need from Bugzilla? (was: My roadmap for a better Fedora)

[Les Mikesell]

Emmanuel Seyman wrote:

>> If someone does this right, maybe it would be possible to cascade all  
>> the way up from user/site/enterprise instances and a working version  
> 
> It could be done. This is why so much work has been done on the XML-RPC
> workings for Bugzilla 3.2.

xml-rpc may be workable for close-coupled systems, like distro-specific 
and an upstream package or branch offices or teams to a central office, 
but it's not going to work for large scale fanout.

>> included in the distribution would have templates for all the packages  
>> and a checkbox for whether or not to push a specific entry upstream or  
>> not.
> 
> Deciding to push a bug upstream or not cannot be reduced to checking a
> box or pushing a button.

Wrong answer, if anyone actually wants those bug reports.

> You need to search the upstream bug tracker
> before submitting and link your bug to an already existing bug in
> upstream if it already exists, fill in new fields and make sure that
> the fields that are dropped don't make the bug incomprehensible.

Then you haven't made anything easier.  It really does have to be a 
'check this box' choice if you want to get them.  What if you had a mail 
transport option, hooked to something resembling a moderated mailman 
list upstream for every pre-configured category where you would like 
reports?  The 'send upstream' option would send something both 
human-readable and machine-parsable to the list.  The receiving list 
would have the option to auto-reply with instructions to the user as to 
where and how to manually re-enter this bug, or to auto-create a new bug 
for the package (that might need to be merged with lots of others 
later), or something in between that the moderator(s) could choose. It 
might even be possible for such a thing to exist as a real mail list 
answered by humans or that it could attract volunteers for moderating 
the input into the right places.   In any case an approach like this 
sounds feasible whereas expecting an end user with a problem to figure 
out what some upstream tracker's peculiar fields means is not.  But, 
once someone arbitrated the inbound message to the right place, 
subsequent correspondence would just work, more or less.

And, of course you would want this mechanism to be able to cascade 
downstream too, so any organization could use it to track local problems 
with the option to push it up to the next level, whatever that might be, 
without having to be completely aware of how to do that correctly.

-- 
    Les Mikesell
     lesmikesell at gmail.com