qpid-proton mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Darryl L. Pierce" <dpie...@redhat.com>
Subject Re: Additional components for language bindings?
Date Mon, 04 Feb 2013 21:27:28 GMT
On Mon, Feb 04, 2013 at 02:15:29PM -0500, Rafael Schloming wrote:
> This is in interesting question. The implementations do share a lot, so
> it's actually quite likely that bugs will occur in the engine rather than
> in the binding itself. My initial impression is that it will be difficult
> to categorize correctly against the proper software component on first
> blush, e.g. say Messenger.get() is not returning a message or blowing up
> under some circumstance. This could be due to an interop issue with another
> implementation, a bug in the C engine, or a bug in the binding itself, and
> it might not be obvious which until we do some investigation/debugging.
> It strikes me that we really have two independent pieces of information to
> capture here, (1) the bindings in which the bug manifests, and (2) the
> software component that is ultimately determined to be at fault. The
> potential drawback of using components to represent both of these is that
> for every engine bug we're likely to get a duplicate report from every
> binding.
> I'm just thinking out loud here, and I'm not a JIRA expert, so I don't know
> exactly what's possible, but it might be worth considering adding a custom
> field for the binding(s) under which the issue occurs and reserving
> component for whatever is actually at fault. This way it's possible we
> might get people to augment the first occurence of the bug with additional
> bindings and actually provide a valuable clue that it's a problem with the
> engine because it occurs in multiple bindings.

I was thinking that the reporter would write up their JIRA issue and say
where they found there error. So the component would reflect that. I
don't think someone who's writing a Ruby app is going to know if the bug
is in the wrapper or in the underlying code, so just letting them report
it against the bindings where they're seeing it would make it easier for
us to get to where it may be initially.

Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.

View raw message