Additional components for language bindings?

["Darryl L. Pierce" <dp...@redhat.com>]

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/

Re: Additional components for language bindings?

["Darryl L. Pierce" <dp...@redhat.com>]

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.
http://www.redhat.com/promo/vendor/

Re: Additional components for language bindings?

["Darryl L. Pierce" <dp...@redhat.com>]

On Tue, Feb 05, 2013 at 08:58:04AM -0500, Rajith Attapattu wrote:
> 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.

+1 - That sounds good to me.

-- 
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/

Re: Additional components for language bindings?

[Rajith Attapattu <ra...@gmail.com>]

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 <ra...@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 <rh...@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 <dp...@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/
>>>
>>>

Re: Additional components for language bindings?

[Rajith Attapattu <ra...@gmail.com>]

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 <rh...@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 <dp...@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/
>>
>>

Re: Additional components for language bindings?

[Rafael Schloming <rh...@alum.mit.edu>]

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 <dp...@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/
>
>