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

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

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

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