You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Andrew McIntyre <mc...@gmail.com> on 2006/03/31 22:45:58 UTC
Regression checkbox (was Re: Can we change SQL State?)
On 3/31/06, David W. Van Couvering <Da...@sun.com> wrote:
>
> I think notification is great. I don't understand why what you are
> suggesting should be "components" they really seem to me to make sense
> as checkboxes -- how are these "components" of the system? Andrew, can
> you explain?
I had misunderstood Kathey's request earlier. I agree that checkboxes
for this behavior would be good to have to flag issues as regressive
behavior, with an additional checkbox for release notes impact, and
leaving the Regression Test Failure component specifically for test
failures. I'm wondering though, if "Existing Application Impact" is
perhaps redundant? In what situations would a behavior be a
regression, need specific mentioning in the release notes, and not
have an impact on existing applications?
andrew
Re: Regression checkbox (was Re: Can we change SQL State?)
Posted by Andrew McIntyre <mc...@gmail.com>.
On 3/31/06, Andrew McIntyre <mc...@gmail.com> wrote:
>
> I had misunderstood Kathey's request earlier. I agree that checkboxes
> for this behavior would be good to have to flag issues as regressive
> behavior, with an additional checkbox for release notes impact, and
> leaving the Regression Test Failure component specifically for test
> failures.
Sorry for the JIRA blast, I needed to move the issues with Patch
Available to a new custom field so that we could add additional
checkboxes. But, seems like a good opportunity for the committers to
review the issues with patches available.
andrew
reviewing patches? (was: Re: Regression checkbox (was Re: Can we
change SQL State?))
Posted by Andreas Korneliussen <An...@Sun.COM>.
Great! Now that we have the check boxes in place, would anyone care to
review the actual patches ? :-)
Andreas
David W. Van Couvering wrote:
> Great, thanks for the quick attention to this!
>
> David
>
> Andrew McIntyre wrote:
>> On 3/31/06, Kathey Marsden <km...@sbcglobal.net> wrote:
>>
>>> It is the other way around. ":Existing Application Impact" is for
>>> things that are not regressions but rather intentional behaviour
>>> changes or fixes that might affect existing applications. An example
>>> might be a bug fix that made Derby comply with standard behaviour where
>>> it did not before. It may have existing application impact but is not
>>> a regression.
>>
>>
>> Ah, I see. I don't think that was clear from the previous comments.
>> I've added a checkbox for that as well.
>>
>> andrew
Re: Regression checkbox (was Re: Can we change SQL State?)
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
Great, thanks for the quick attention to this!
David
Andrew McIntyre wrote:
> On 3/31/06, Kathey Marsden <km...@sbcglobal.net> wrote:
>
>>It is the other way around. ":Existing Application Impact" is for
>>things that are not regressions but rather intentional behaviour
>>changes or fixes that might affect existing applications. An example
>>might be a bug fix that made Derby comply with standard behaviour where
>>it did not before. It may have existing application impact but is not
>>a regression.
>
>
> Ah, I see. I don't think that was clear from the previous comments.
> I've added a checkbox for that as well.
>
> andrew
Re: Regression checkbox (was Re: Can we change SQL State?)
Posted by Andrew McIntyre <mc...@gmail.com>.
On 3/31/06, Kathey Marsden <km...@sbcglobal.net> wrote:
>
> It is the other way around. ":Existing Application Impact" is for
> things that are not regressions but rather intentional behaviour
> changes or fixes that might affect existing applications. An example
> might be a bug fix that made Derby comply with standard behaviour where
> it did not before. It may have existing application impact but is not
> a regression.
Ah, I see. I don't think that was clear from the previous comments.
I've added a checkbox for that as well.
andrew
Re: Regression checkbox (was Re: Can we change SQL State?)
Posted by Kathey Marsden <km...@sbcglobal.net>.
Andrew McIntyre wrote:
>On 3/31/06, David W. Van Couvering <Da...@sun.com> wrote:
>
>
>>I think notification is great. I don't understand why what you are
>>suggesting should be "components" they really seem to me to make sense
>>as checkboxes -- how are these "components" of the system? Andrew, can
>>you explain?
>>
>>
>
>I had misunderstood Kathey's request earlier. I agree that checkboxes
>for this behavior would be good to have to flag issues as regressive
>behavior, with an additional checkbox for release notes impact, and
>leaving the Regression Test Failure component specifically for test
>failures. I'm wondering though, if "Existing Application Impact" is
>perhaps redundant? In what situations would a behavior be a
>regression, need specific mentioning in the release notes, and not
>have an impact on existing applications?
>
>
>
It is the other way around. ":Existing Application Impact" is for
things that are not regressions but rather intentional behaviour
changes or fixes that might affect existing applications. An example
might be a bug fix that made Derby comply with standard behaviour where
it did not before. It may have existing application impact but is not
a regression.
Kathey