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@xxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
