db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stanley Bradbury <Stan.Bradb...@gmail.com>
Subject Re: 10.3 blocker issue - DERBY-2728
Date Wed, 30 May 2007 17:43:35 GMT
Dag H. Wanvik wrote:
> Myrna van Lunteren <m.v.lunteren@gmail.com> writes:
>
>   
>> Hi,
>>
>> We have a bump in our 10.3 release path - DERBY-2728.
>>     
    =   =   =   = SNIP =  =====
> If we choose to tie enforcement to SQLAuthorization being on, I think
> this is a fairly small patch; the existing tests still have test cases
> for this (authentication + SQLauthorization), so they could be tweaked
> easily too. I expect most work would be to change the documentation
> (DERBY-2520). The release note for DERBY-2264 would need to change as
> well. I'd be willing to do this work if we choose that approach. I'd
> need a week; generally pushing releases less than 2 weeks seems not
> worth it, so I suggest a 2 week delay.
>
> DERBY-2728 speaks about making the semantics optional a *upgrade
> time*, though, which is another approach. This could imply some
> persistence of the fact that the database was upgraded and should have
> different semantics than a freshly created one, or use of extra
> properties.  If someone volunteers to make such a solution, thats fine
> with me.
>
> Note that even if we tie enforcement to SQLAuthorization, some
> existing application may still be impacted, although presumably much
> fewer applications, since this is a 10.2 feature, and already implies
> a database owner concept and is probably less likely to be used in an
> embedded context (Kathey's concern).
>
> Thanks,
> Dag
>
>   
>> Should we make a release candidate while the fixing is in progress?
>>     
   Hi -
Dag's suggestion seems like a best-approach to me.  +1

It solves the problem with a 'fairly small patch' and can be done with 
minimal impact on the release date.   The change will allow people who 
have not already set SQLAuthorization to test the impact of the new DBO 
role on their system and opt out of implementing it at this time.  As 
Dag points out, people who have already stepped up to using 
SQLAuthorization will have identified the DBO account and  designed the 
system accordingly so the change should be less dramatic.

As a side note I think it good to encourage Derby users to plan for and 
implement the DBO role at their earliest convenience.  Once the required 
changes are made and tested the flag can be set and the system will have 
the benefit of improved security.

And the question about: 

Should we make a release candidate while the fixing is in progress?

This seems like extra work for the Release Manager so, unless someone is aware of a critical
need for a full release candidate build in the next week or two I would hold off.  Of course
I am not the Release Manager and it is her call.




Mime
View raw message