Just to clarify further. We could have a component called proton-bindings. And we use a label to denote which binding it is. If the bug turns out to be in the engine, we change the component but retain the labels. If other bindings show the same bug we can add labels.
This way we know which bindings were associated with the bug. Having a component per binding would not allow the above flexibility. Rajith On Mon, Feb 4, 2013 at 2:56 PM, Rajith Attapattu <rajit...@gmail.com> wrote: > We could use lables to denote which binding(s). > The advantage here is that if multiple bindings expose the same bug, > all we need to do is to add an additional label to the same JIRA. > We currently use labels in the JMS client to denote sub categories (Ex > addressing, exception-handling). > The same strategy could be used here. > > Rajith > > On Mon, Feb 4, 2013 at 2:15 PM, Rafael Schloming <r...@alum.mit.edu> 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. >> >> --Rafael >> >> On Thu, Jan 31, 2013 at 9:16 AM, Darryl L. Pierce <dpie...@redhat.com>wrote: >> >>> Should we have separate components in Jira to represent each of the >>> language bindings? If someone were to report a bug against any of them, >>> it seems a little incorrect to report it against proton-c unless it were >>> specifically something under the language covers. >>> >>> I'd like to have the following components if everybody agrees: >>> * proton-ruby >>> * proton-perl >>> * proton-php >>> * proton-c++ >>> * proton-python >>> >>> -- >>> Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. >>> Delivering value year after year. >>> Red Hat ranks #1 in value among software vendors. >>> http://www.redhat.com/promo/vendor/ >>> >>>