Re: 10.4 Feature Freeze
Martin Zaun wrote: [EMAIL PROTECTED] wrote: Daniel John Debrunner <[EMAIL PROTECTED]> writes: [EMAIL PROTECTED] wrote: Here is the current status (based on what I know): Feature Status -- System privilegesOn track Have you any more information on the state of this? a) The latest patch, just published, addresses the J2ME/CDC failures; I hope this blocking issues is resolved, but we probably want to wait for some confirming J2ME/CDC test results. I'm not aware of other, major objections, and it was suggested to handle follow-up and polishing items in a separate JIRA. The format of SystemPrincipal identifiers in policy files (and as the argument SystemPrincipal's constructor) does not match what a technical discussion in DERBY-2109 decided, see DERBY-3477. This is due an unforeseen limitation in the way the Java security implementation handles Principal names in policy files. The resulting format implemented by the patch does not really make sense (not the implementor's fault, it's due to the limitation) and will be hard to explain to users (connection requests that lead to identical database identifiers end up with different permissions). An implementation cannot be driving a format that is security critical and part of the Derby's public api. In addition in trying to work around the format limitations a security hole has been introduced (I'll add details to DERBY-3477). Then the addition of JMX using system permissions has led to the realization that the names don't match the expected format for permissions in terms of "name" (object the permission applies to) and "actions" (actions on that object). This can often happen when a single use of an object is expanded. So while I think there are no major objections to the current patch (I haven't looked at v12 yet), I don't think the remaining items should be seen as just polishing, and thus they may take some amount of effort including some design. I see the current patch as a great step forward, but somewhat flawed, but provides a framework to proceed. Thus while the work done specifically in DERBY-2109 may be near to completion, its sub-tasks and related issues may not be and I think those need to be completed before a release. Mainly because they are both defining public api's and are security related, both things that we as a community should try to get right thus not having to deal with changing formats and backwards compatibility later. Dan.
Re: 10.4 Feature Freeze
[EMAIL PROTECTED] wrote: Daniel John Debrunner <[EMAIL PROTECTED]> writes: [EMAIL PROTECTED] wrote: Here is the current status (based on what I know): Feature Status -- System privilegesOn track Have you any more information on the state of this? a) The latest patch, just published, addresses the J2ME/CDC failures; I hope this blocking issues is resolved, but we probably want to wait for some confirming J2ME/CDC test results. I'm not aware of other, major objections, and it was suggested to handle follow-up and polishing items in a separate JIRA. b) Due to some functional changes applied over the last weeks (e.g. checks for authorization regardless of prior authentication) and some limitations that can't be worked around (e.g. regarding Authorization Ids in policy files), I've planned to restate the exact compatibility issues of System Privileges for derby-dev. This discussion about further options (to be handled in a separate JIRA, I think) and documentable restrictions might take 1-2 weeks. c) There's a documentation task for System Privileges (derby guides), which can partly overlap with b) and also might take 1-2 calendar weeks (need to get to know the documentation-related tools). d) Finally, I have some tests that need some more work before they can be included in the test suites. While I'm cautiously optimistic about a) and hope that d) can be checked in later, I'm not sure what people think about b) and c) being a requirement for feature freeze. Martin
Re: 10.4 Feature Freeze
Dyre Tjeldvoll <[EMAIL PROTECTED]> writes: > Knut Anders Hatlen wrote: >> [EMAIL PROTECTED] writes: >> >>> ... is fast approaching (2008-02-29) >>> >>> Is this still a reasonable date, or should we consider delaying it? >>> >>> >>> Here is the current status (based on what I know): >> [...] >>> Buffer manager On track >> >> Hi Dyre, >> >> The code for the buffer manager has been in the repository for quite >> some time now, but it has not yet been enabled in >> modules.properties. Øystein has reviewed the code and suggested some >> improvements. I'll probably not have the time to make all the changes >> Øystein suggested before the feature freeze date, but since the >> improvements are mainly reorganizing some methods and improving the >> comments, I think we could just as well enable it now before the >> improvements have been made. I have just asked about it on JIRA, and >> I'll wait until someone says go ahead before I enable it. >> > > Ok, thanks for the update. Unless enabling it will make it difficult > to address the review comments, I'd say go ahead. Thanks, I just did. I hope it doesn't break anything... -- Knut Anders
Re: 10.4 Feature Freeze
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.
Re: 10.4 Feature Freeze
Knut Anders Hatlen wrote: [EMAIL PROTECTED] writes: ... is fast approaching (2008-02-29) Is this still a reasonable date, or should we consider delaying it? Here is the current status (based on what I know): [...] Buffer manager On track Hi Dyre, The code for the buffer manager has been in the repository for quite some time now, but it has not yet been enabled in modules.properties. Øystein has reviewed the code and suggested some improvements. I'll probably not have the time to make all the changes Øystein suggested before the feature freeze date, but since the improvements are mainly reorganizing some methods and improving the comments, I think we could just as well enable it now before the improvements have been made. I have just asked about it on JIRA, and I'll wait until someone says go ahead before I enable it. Ok, thanks for the update. Unless enabling it will make it difficult to address the review comments, I'd say go ahead. Dyre
Re: 10.4 Feature Freeze
Anurag Shekhar wrote: [EMAIL PROTECTED] wrote: ... is fast approaching (2008-02-29) Is this still a reasonable date, or should we consider delaying it? Unique constraints On track I have all the patches (3 of them) in jira and there are chances that they might get commited before 29th but having one more week in hand will be lot more comfortable. Ok, noted. Also I would like write a couple of multi threaded tests to test locking behavior of unique constraint. Sounds like a good idea, :) Dyre
Re: 10.4 Feature Freeze
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. 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? 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.
Re: 10.4 Feature Freeze
[EMAIL PROTECTED] writes: > ... is fast approaching (2008-02-29) > > Is this still a reasonable date, or should we consider delaying it? > > > Here is the current status (based on what I know): [...] > Buffer manager On track Hi Dyre, The code for the buffer manager has been in the repository for quite some time now, but it has not yet been enabled in modules.properties. Øystein has reviewed the code and suggested some improvements. I'll probably not have the time to make all the changes Øystein suggested before the feature freeze date, but since the improvements are mainly reorganizing some methods and improving the comments, I think we could just as well enable it now before the improvements have been made. I have just asked about it on JIRA, and I'll wait until someone says go ahead before I enable it. -- Knut Anders
Re: 10.4 Feature Freeze
Daniel John Debrunner wrote: [EMAIL PROTECTED] wrote: John Embretsen <[EMAIL PROTECTED]> writes: [EMAIL PROTECTED] wrote: ... is fast approaching (2008-02-29) Is this still a reasonable date, or should we consider delaying it? Here is the current status (based on what I know): JMX On track JMX is on track per se, as it has not been defined what exactly will be part of 10.4. However, this is still work in progress, but I guess it is up to you as release manager to decide what to let into the release or not. It is, but some JMX stuff has already been committed, hasn't it. And since what Derby offers through JMX isn't regulated by a standard, I would think that you have quite a bit of leeway in terms of defining when the feature is complete... :) 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. Martin is actively working on this feature and deserves our patience and respect. Each rework/retest cycle is turning out to be very expensive. -Rick
Re: 10.4 Feature Freeze
[EMAIL PROTECTED] wrote: ... is fast approaching (2008-02-29) Is this still a reasonable date, or should we consider delaying it? Unique constraints On track I have all the patches (3 of them) in jira and there are chances that they might get commited before 29th but having one more week in hand will be lot more comfortable. Also I would like write a couple of multi threaded tests to test locking behavior of unique constraint. anurag
Re: 10.4 Feature Freeze
[EMAIL PROTECTED] wrote: John Embretsen <[EMAIL PROTECTED]> writes: [EMAIL PROTECTED] wrote: ... is fast approaching (2008-02-29) Is this still a reasonable date, or should we consider delaying it? Here is the current status (based on what I know): JMX On track JMX is on track per se, as it has not been defined what exactly will be part of 10.4. However, this is still work in progress, but I guess it is up to you as release manager to decide what to let into the release or not. It is, but some JMX stuff has already been committed, hasn't it. And since what Derby offers through JMX isn't regulated by a standard, I would think that you have quite a bit of leeway in terms of defining when the feature is complete... :) 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.
Re: 10.4 Feature Freeze
Kristian Waagan wrote: [EMAIL PROTECTED] wrote: ... is fast approaching (2008-02-29) Is this still a reasonable date, or should we consider delaying it? [snip - other work going on] Client stm cache On track I'm still working hard to get this done. In my last run of suites.All with connections obtained from CPDS (I'm only able to easily force this for the tests calling defaultSuite / clientServerDecorator), I had 14 failures and 4 errors. When I ran with CPDS but statement pooling disabled, I got 13 failures, which I believe indicates that there are existing bugs in the logical connection implementation in the client driver. See DERBY-3440 for some more details. Note that with the TestConfiguration hack, around 3100 connections out of a total of around 9500 are obtained through CPDS, so the coverage is far from complete, and I don't believe I can expect that either. Known remaining work: (DERBY-3440 : Run suites.All with statement pooling enabled and classify the problems occurring) DERBY-3441 : Determine and implement a proper procedure for resetting a prepared statement for reuse in a statement pool - awaiting review DERBY-3329 : Enable statement pooling in the client JDBC driver - trivial, have patch already DERBY-3457 : Closing a logical connection must close all associated logical statements - awaiting review DERBY-3446 : Commit the test. DERBY-3326 : Fix bug regarding prepareStatement(String,String[]|int[]) - awaiting review DERBY-3326 : Integrate DERBY-3192 (assumed to be trivial) In addition, there are the JIRAs for existing bugs in the client driver affecting statement pooling (or more specifically connection pooling). See comment in DERBY-3440 for a list. It might not be exhaustive. As an additional testing step I hope to run a J2EE test with statement pooling enabled, to see if any new problems show up. Thank you for a great summary. While there is some work left, this doesn't strike me as problematic. It seems like the feature will be largely complete in time for feature freeze. I certainly don't expect you to fix all existing bugs in the connection pool implementation before feature freeze just because your testing has uncovered them... Finally, if you feel I'm moving too fast and committing patches too quickly, let me know. Or better yet, review the patches and give me feedback :) I'm trying to let the patches sit in JIRA for a short while, but taken the short time until feature freeze, I don't have the time to wait for days for each patch. I don't see this as a problem. It is still possible to review patches post commit and you have been very vocal on the list about what you do. I feel I can take this liberty because I'm mostly working on new code and my changes don't disturb the work of other contributers. And, the changes won't affect users unless they choose to use the feature, and the feature can be disabled by modifying a single class. +1 But if you prefer to have more time you could join the replication guys and argue for a one week extension. Dyre
Re: 10.4 Feature Freeze
[EMAIL PROTECTED] wrote: ... is fast approaching (2008-02-29) Is this still a reasonable date, or should we consider delaying it? [snip - other work going on] Client stm cache On track I'm still working hard to get this done. In my last run of suites.All with connections obtained from CPDS (I'm only able to easily force this for the tests calling defaultSuite / clientServerDecorator), I had 14 failures and 4 errors. When I ran with CPDS but statement pooling disabled, I got 13 failures, which I believe indicates that there are existing bugs in the logical connection implementation in the client driver. See DERBY-3440 for some more details. Note that with the TestConfiguration hack, around 3100 connections out of a total of around 9500 are obtained through CPDS, so the coverage is far from complete, and I don't believe I can expect that either. Known remaining work: (DERBY-3440 : Run suites.All with statement pooling enabled and classify the problems occurring) DERBY-3441 : Determine and implement a proper procedure for resetting a prepared statement for reuse in a statement pool - awaiting review DERBY-3329 : Enable statement pooling in the client JDBC driver - trivial, have patch already DERBY-3457 : Closing a logical connection must close all associated logical statements - awaiting review DERBY-3446 : Commit the test. DERBY-3326 : Fix bug regarding prepareStatement(String,String[]|int[]) - awaiting review DERBY-3326 : Integrate DERBY-3192 (assumed to be trivial) In addition, there are the JIRAs for existing bugs in the client driver affecting statement pooling (or more specifically connection pooling). See comment in DERBY-3440 for a list. It might not be exhaustive. As an additional testing step I hope to run a J2EE test with statement pooling enabled, to see if any new problems show up. Finally, if you feel I'm moving too fast and committing patches too quickly, let me know. Or better yet, review the patches and give me feedback :) I'm trying to let the patches sit in JIRA for a short while, but taken the short time until feature freeze, I don't have the time to wait for days for each patch. I feel I can take this liberty because I'm mostly working on new code and my changes don't disturb the work of other contributers. And, the changes won't affect users unless they choose to use the feature, and the feature can be disabled by modifying a single class. -- Kristian Session data caching On track Buffer manager On track More info can be found at http://wiki.apache.org/db-derby/DerbyTenFourRelease Thanks,
Re: 10.4 Feature Freeze
Daniel John Debrunner wrote: [EMAIL PROTECTED] wrote: Here is the current status (based on what I know): Feature Status -- System privilegesOn track Have you any more information on the state of this? Martin said he was working on a new patch on 02/13 but nothing since then. I asked yesterday if a new patch was coming up but no reply yet. I think that Martin is close to posting a patch for this. He hasn't responded yet but I suspect he is polishing some corner case. I would give him time to respond. VTI Completed Has a potential data corrupting bug associated with it DERBY-3341 Dan.
Re: 10.4 Feature Freeze
Daniel John Debrunner wrote: [EMAIL PROTECTED] wrote: Here is the current status (based on what I know): Feature Status -- System privilegesOn track Have you any more information on the state of this? Martin said he was working on a new patch on 02/13 but nothing since then. I asked yesterday if a new patch was coming up but no reply yet. VTI Completed Has a potential data corrupting bug associated with it DERBY-3341 I will take a look at this one. Regards, -Rick Dan.
Re: 10.4 Feature Freeze
[EMAIL PROTECTED] writes: > SQL rolesDelayed (disabled) To clarify, not disabled on trunk, but will be on the 10.4 branch, tracked by DERBY-3460. Dag
Re: 10.4 Feature Freeze
Daniel John Debrunner <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] wrote: > >> Here is the current status (based on what I know): >> >> Feature Status >> -- > >> System privilegesOn track >Have you any more information on the state of this? Nope. I just assumed that since there had been no "won't be done" warning, is was still targeted for 10.4. > Martin said he was working on a new patch on 02/13 but nothing since > then. I asked yesterday if a new patch was coming up but no reply yet. I see. I have not followed that discussion closely, and was under the impression that the remaining issues were minor ones. > >> VTI Completed >Has a potential data corrupting bug associated with it DERBY-3341 I did not know that. I'll take a look. -- dt
Re: 10.4 Feature Freeze
John Embretsen <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] wrote: >> ... is fast approaching (2008-02-29) >> >> Is this still a reasonable date, or should we consider delaying it? >> >> >> Here is the current status (based on what I know): > >> JMX On track > > JMX is on track per se, as it has not been defined what exactly will be part > of > 10.4. However, this is still work in progress, but I guess it is up to you as > release manager to decide what to let into the release or not. It is, but some JMX stuff has already been committed, hasn't it. And since what Derby offers through JMX isn't regulated by a standard, I would think that you have quite a bit of leeway in terms of defining when the feature is complete... :) > > I have plans to contribute some JMX tests (DERBY-3385; might submit something > today, but then I'll be on vacation for about a week). There are also some > minor > changes that I would like to get in to 10.4 (proper Javadocs and minor MBean > interface changes (DERBY-1387)), unless someone else takes care of it. So, I > would appreciate some more time (one week, maybe two) to get this in. > > I also believe Bernt is working on improving one of the MBeans (DERBY-3435), > and > I think Dan may have some patches in the pipeline (DERBY-3429, DERBY-3462, ?), > but I'll let them speak for themselves regarding the feature freeze date. I would think that all of these things could be added after feature freeze, if need be. They don't seem like things that could seriously de-stabilize the branch...(?) -- dt
Re: 10.4 Feature Freeze
[EMAIL PROTECTED] wrote: Here is the current status (based on what I know): Feature Status -- System privilegesOn track Have you any more information on the state of this? Martin said he was working on a new patch on 02/13 but nothing since then. I asked yesterday if a new patch was coming up but no reply yet. VTI Completed Has a potential data corrupting bug associated with it DERBY-3341 Dan.
Re: 10.4 Feature Freeze
Jørgen Løland <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] wrote: >> Replication On track > > The 10.4 replication functionality is done, but I would be a lot more > confident in this new functionality if we had the time to add a lot of > tests. I would prefer that we move code-freeze to end of next week to > add tests, but I'll leave that decision to you. I don't have a problem with this myself, but I would like to know what the community thinks before making a decision. -- dt
Re: 10.4 Feature Freeze
Bryan Pendleton <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] wrote: >> Here is the current status (based on what I know): > > Hi Dyre, thanks for all the great work on the 10.4 release! > > I think we should remove the OLAP item from the list, as > we haven't made much progress on it and there won't be > much done for OLAP in the 10.4 release. It's possible that we'll get > DERBY-2998 done, so maybe replace the general OLAP item > with just the DERBY-2998 target? Ok, sounds reasonable. > > I tried to edit the wiki myself but got some sort of > internal "wiki is down" error. Are you getting similar errors? No, but it has been a while since I edited anything. I'll try it and see what happens. -- dt
Re: 10.4 Feature Freeze
Bryan Pendleton wrote: [EMAIL PROTECTED] wrote: Here is the current status (based on what I know): Hi Dyre, thanks for all the great work on the 10.4 release! I think we should remove the OLAP item from the list, as we haven't made much progress on it and there won't be much done for OLAP in the 10.4 release. It's possible that we'll get DERBY-2998 done, so maybe replace the general OLAP item with just the DERBY-2998 target? I tried to edit the wiki myself but got some sort of internal "wiki is down" error. Are you getting similar errors? I'm not, but maybe the error has been fixed already. -- Kristian thanks, bryan
Re: 10.4 Feature Freeze
[EMAIL PROTECTED] wrote: Here is the current status (based on what I know): Hi Dyre, thanks for all the great work on the 10.4 release! I think we should remove the OLAP item from the list, as we haven't made much progress on it and there won't be much done for OLAP in the 10.4 release. It's possible that we'll get DERBY-2998 done, so maybe replace the general OLAP item with just the DERBY-2998 target? I tried to edit the wiki myself but got some sort of internal "wiki is down" error. Are you getting similar errors? thanks, bryan
Re: 10.4 Feature Freeze
[EMAIL PROTECTED] wrote: Replication On track The 10.4 replication functionality is done, but I would be a lot more confident in this new functionality if we had the time to add a lot of tests. I would prefer that we move code-freeze to end of next week to add tests, but I'll leave that decision to you. -- Jørgen Løland
Re: 10.4 Feature Freeze
[EMAIL PROTECTED] wrote: SQL OLAP (row-number)On track I hope to be able to wrap up the ROW_NUMBER() work over the next couple of days - but no guarantee as of now. Thomas -- Thomas Nielsen
Re: 10.4 Feature Freeze
[EMAIL PROTECTED] wrote: ... is fast approaching (2008-02-29) Is this still a reasonable date, or should we consider delaying it? Here is the current status (based on what I know): JMX On track JMX is on track per se, as it has not been defined what exactly will be part of 10.4. However, this is still work in progress, but I guess it is up to you as release manager to decide what to let into the release or not. I have plans to contribute some JMX tests (DERBY-3385; might submit something today, but then I'll be on vacation for about a week). There are also some minor changes that I would like to get in to 10.4 (proper Javadocs and minor MBean interface changes (DERBY-1387)), unless someone else takes care of it. So, I would appreciate some more time (one week, maybe two) to get this in. I also believe Bernt is working on improving one of the MBeans (DERBY-3435), and I think Dan may have some patches in the pipeline (DERBY-3429, DERBY-3462, ?), but I'll let them speak for themselves regarding the feature freeze date. -- John
