db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: Should we vote on it? (was Re: Discussion (in preparation for a vote) on interface stability table)
Date Fri, 31 Mar 2006 19:32:18 GMT
I don't know the specific bug and the impact.  My intuition says 
document the change.  But if it were a significant enough change, I 
might consider providing support for the old, broken behavior.  I hope 
that this is a discussion that can be had around this bug by the 
contributor and his/her reviewers.

David

Rick Hillegas wrote:
> We already have to cross this bridge for the next release of Derby. 
> DERBY-280 is a correctness bug, which while not fixed, was patched. This 
> changes the behavior of a family of queries which were returning wrong 
> results. What should we do:
> 
> 1) Add and document a tracepoint allowing customers to get the previous 
> incorrect behavior? Please say no. I think we all believe this is a 
> crummy solution.
> 2) Document the changed behavior in the Release Notes. If an important 
> customer complains, then we can evaluate how to satisfy that customer in 
> a follow-on release.
> 3) Something else?
> 
> -Rick
> 
> David W. Van Couvering wrote:
> 
>> I agree this sounds like a terrible model.  But we have to accept 
>> reality, we *are* going to have bugs.  And if we can't fix those bugs 
>> in a backward-compatible way, then it is more than likely that some 
>> Big Huge Customer will refuse to upgrade.  I saw that at Sybase as 
>> well. Perhaps the cost of supporting older codelines is ultimately a 
>> better choice for our product than the spaghetti of micro-compatbility 
>> if-statements and weird "behavior plugins" in the code.
>>
>> I don't have an easy answer.  I agree we should strive for 
>> correctness, and perhaps we'll just have to cross that bridge when we 
>> come to it.  I think Rick's caveats are valuable, but I don't want 
>> them to be a loophole that we then use to feel we have more free rein 
>> to break compatibility.  But, saying that, knowing this lot I suspect 
>> we don't have to worry about this, you can't sneeze around here 
>> without someone worrying whether than sneeze was compatible with your 
>> last sneeze :)
>>
>> David
>>
>> Daniel John Debrunner wrote:
>>
>>> Rick Hillegas wrote:
>>>
>>>
>>>> Thanks, David. I think this discussion is raising some interesting 
>>>> issues.
>>>>
>>>> David W. Van Couvering wrote:
>>>>
>>>>
>>>>>> 2) Bug fixing policy.
>>>>>>
>>>
>>>
>>>> I am glad that we are bothering to make these rules explicit. In a
>>>> previous life at Sybase, we solved this problem by adding special
>>>> tracepoints for big, important customers who relied on old, incorrect
>>>> behavior. As I recall, we didn't know up front who would object to a
>>>> correction. The tracepoints went into patch releases based on customer
>>>> dissatisfaction with the last minor release.
>>>>
>>>> Do you think the Sybase model will work for us? Or do we need to add
>>>> tracepoints to the minor release as we fix the incorrect behavior? 
>>>> Maybe
>>>> it is not good enough to add a master tracepoint with the semantics
>>>> "Simulate all incorrect implementations of the standards fixed in this
>>>> release, X.y." Customers may want something more granular, say, a
>>>> tracepoint per obnoxious correction. Over time, these tracepoints will
>>>> pile up and the code will  become a more exciting pinball machine. What
>>>> are your thoughts?
>>>
>>>
>>>
>>>
>>> I think it's a terrible model. This moves the project into a state where
>>> the number of possible execution time modes will increase rapidly,
>>> causing nightmares for those who have to support it or answer questions
>>> on the user list.
>>>
>>> For any change we as a community should be confident it is the correct
>>> change.
>>>
>>> [disclaimer - I was at Sybase during those times ]
>>>
>>> Dan.
>>>
> 

Mime
View raw message