db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: 10.4 Feature Freeze
Date Wed, 27 Feb 2008 22:08:31 GMT
Daniel John Debrunner wrote:
> Rick Hillegas wrote:
>> Daniel John Debrunner wrote:
>>> I'm trying to add Java security manager checks (DERBY-3462) to the 
>>> JMX MBeans so that security is not compromised by the addition of 
>>> JMX. While I'm not blocked by DERBY-2109, if I proceed ahead of 
>>> DERBY-2019 committing code JMX related permission code then any 
>>> DERBY-2109 patch will have to re-worked again. However since there 
>>> doesn't seem to be any activity on DERBY-2109 I may just go ahead 
>>> anyway.
>>> Dan.
>> Please do not do this, at least not in a way which will make it 
>> necessary to rework and retest DERBY-2109.
> I'll avoid doing this, I think there is a temp workaround I can do. If 
> we get to the branch cutoff though without any progress on DERBY-2109 
> then changes may need to be made.
Thanks, Dan.
>> Martin is actively working on this feature and deserves our patience 
>> and respect.
> That's great, but you have to look at it from the issue of activity on 
> the list: Given no messages for over two weeks from any contributor 
> there are a number of scenarios one can imagine from not being active 
> on derby anymore to being stuck on a problem that the community could 
> possibly help with. Without communication it's impossible to tell so 
> one has to assume not active if one wants to fry a fish in the same or 
> overlapping area.
>> Each rework/retest cycle is turning out to be very expensive.
> Is there a way the community could help, posting a newer version of 
> the patch, helping solve issues, running the tests on various platforms?
It looks as though Martin has posted a comment on DERBY-2109.
> I think this patch would have benefited from continuing the 
> incremental development approach it started with. The current patch is 
> trying to solve at least four issues. With an incremental approach my 
> opinion is that most of the current patch's functionality could have 
> already been committed, allowing focus on specific problems and a 
> quicker turn-around on testing etc. I wonder if some folks are 
> reluctant to perform incremental development because they think 
> patches are too slow to be applied, thus they do a mega-patch which of 
> course will take time to commit, thus we have a self-fulfilling prophecy?
> Dan.

View raw message