Copyrights redux

Hi Jean, I wanted to confirm with you what we should do about copyright notices. Copyright notices seem to appear in three places: 1) On the Derby website 2) In the published user guides which we bundle with releases 3) In the Derby source code, including the source code for the web site

Re: Copyrights redux

Hi Jean, While I'm on the topic: I asked these questions in the context of 10.2, but it seems that issue (2) may apply to 10.1.3 as well. Do the copyright notices for the 10.1.3 release need to conform to the pattern in (2)? Thanks, -Rick Rick Hillegas wrote: Hi Jean, I wanted

Driver autoloading and engine booting

This topic was raised in an earlier email thread (http://comments.gmane.org/gmane.comp.apache.db.derby.devel/20899) but it does not appear that we agreed on a solution. I would like to re-open this topic and hopefully we can converge on how we want to handle this issue. Olav has analyzed a

Re: [jira] Commented: (DERBY-930) Add support for autoloading of Derby client drivers

Hi Bryan, Thanks for the quick response. I have revised the release note. Hopefully, it now describes the VM-specific issues better. Regards, -Rick Bryan Pendleton wrote: Rick Hillegas (JIRA) wrote: Adding a release note for this issue: Hi Rick, thanks for writing the release note

Re: Driver autoloading and engine booting

Kathey Marsden wrote: David Van Couvering wrote: - Log a bug - Work on fixing it by booting on first connection rather than when the driver is loaded. It would be good to get input from the user community as well. One possible approach would be to log the bug, mark it as a regression,

Re: interested in working on DERBY-713

Hi Brent, Sounds like you're off to a good start. From the initial bug report, it looks like there's a good idea about which heuristic is being mis-applied here. Once you've studied the optimizer papers, I recommend that you post some high-level candidate solutions. Try to avoid optimizer

Re: Driver autoloading and engine booting

Jean T. Anderson wrote: Rick Hillegas wrote: Kathey Marsden wrote: David Van Couvering wrote: - Log a bug - Work on fixing it by booting on first connection rather than when the driver is loaded. It would be good to get input from the user community as well. One

Re: Driver autoloading and engine booting

Kathey Marsden wrote: Rick Hillegas wrote: I'm afraid I don't understand why we would want to revert our tests to the old behavior. It seems to me that our tests are practicing stunts which we strongly discourage: changing Derby properties on the fly. In general, there will always

Re: How to best handle variations in output from ij in sql tests?

Hi Olav, Thanks for digging into this. The differences in the embedded output are caused by JDBC4's introduction of SQLException subclasses. These now replace Derby's hand-rolled subclass of SQLException. The old Derby subclass overrode the getMessage() method. That's why you used to see

Optimizer issue, was: interested in working on DERBY-713

this wall a bit, to get a better understanding of things, instead of being pointed immediately to the solution -- my own version of smelling the roses, I guess ;-) Cheers! Brent [2006-06-19 11:30] Rick Hillegas said: | Hi Brent, | | Sounds like you're off to a good start. From the initial bug

Re: [jira] Commented: (DERBY-578) Grouped select from temporary table raises null pointer exception in byte code generator

the subquery.out file yourself or should I attach another patch? Do you want the entire patch or just subquery.diff? On 6/20/06, *Rick Hillegas (JIRA)* derby-dev@db.apache.org mailto:derby-dev@db.apache.org wrote: [ http://issues.apache.org/jira/browse/DERBY-578?page=comments

Re: Optimizer issue, was: interested in working on DERBY-713

. Regards, -Rick Mike Matrigali wrote: Rick Hillegas wrote: Hi Brent, ... Plan 3: Join / \ Union TableScan / \ IndexScan IndexScan Each IndexScan would probe for a single key value. If you could just get

Re: Driver autoloading and engine booting

Kathey Marsden wrote: Rick Hillegas and Kathey Marsden wrote: [lots of stuff about implementation details that probably should wait a bit] I think Dan's summary and focus on goals was good: Dan said ... I think the goal should be to support auto-loading and to ensure applications

Re: [PRE-VOTE DISCUSSION] Compatibility rules and interface table

Hi David, I had a couple more comments on the compatibility commitments. Cheers-Rick - Changes to stored procedures: We will have to change column order if we add Derby-specific columns to a metadata ResultSet and then a later JDBC also adds more columns. - Changes to Database Tables: We

Re: [PRE-VOTE DISCUSSION] Compatibility rules and interface table

David Van Couvering wrote: Rick Hillegas wrote: Hi David, I had a couple more comments on the compatibility commitments. Cheers-Rick - Changes to stored procedures: We will have to change column order if we add Derby-specific columns to a metadata ResultSet and then a later JDBC

Re: [jira] Updated: (DERBY-1271) Release documentation for JDBC4 release

Edition is supposed to capture, perhaps the Edition lines should be moved to a comments section so that they will not be visible/confusing to customers. Regards, -Rick Jean T. Anderson wrote: Rick Hillegas (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-1271?page=all ] Rick

Re: ADVICE REQUESTED: Fixing MessageBundleTest

Hi David, You might want to wrap the test in a custom Ant Task. These are described in the Ant manual: Developing with Ant-Writing Your Own Task. You can then check the return status of the task and fail the build if appropriate. Regards, -Rick David Van Couvering wrote: Hm, a build-time

Re: [jira] Updated: (DERBY-1271) Release documentation for JDBC4 release

Jean T. Anderson wrote: Rick Hillegas wrote: Thanks, Jean. The Edition line turns up in the visible text which appears in the printed document. That makes me think that it applies to something that the customer, the reader, cares about. I don't think the reader is particularly concerned

Re: [jira] Updated: (DERBY-1271) Release documentation for JDBC4 release

Daniel John Debrunner wrote: Rick Hillegas wrote: Jean T. Anderson wrote: Rick Hillegas wrote: Thanks, Jean. The Edition line turns up in the visible text which appears in the printed document. That makes me think that it applies to something that the customer, the reader

Re: [jira] Updated: (DERBY-1271) Release documentation for JDBC4 release

+1 Regards, -Rick Jean T. Anderson wrote: Jeff Levitt wrote: snip As the person who contributed the DITA-converted documentation, I can tell you I didn't bump the edition up based on that. I believe the pre-DITA documentation already said Second Edition. The pre-DITA (10.0) doc

Proposal for 10.2 release schedule

Last week, Sun Microsystems announced that it will bundle Derby with the next major release of the reference jdk, Java SE 6, also known as Mustang or jdk1.6. If you download the latest Mustang build, you will see that it contains our Derby 10.2.0.3 snapshot in the db directory parallel to lib

Re: Proposal for 10.2 release schedule

Hi Kathey, Thanks for raising these issues. Here are some clarifications. Regards, -Rick Kathey Marsden wrote: Rick Hillegas wrote: The JCP requires that our JDBC4-exposing release can not be generally available until the JDBC4 specification is finalized. Is this something

Re: Proposal for 10.2 release schedule

Daniel John Debrunner wrote: Rick Hillegas wrote: Hi Dan, Thanks for your comments. Some further remarks follow. Regards, -Rick Daniel John Debrunner wrote: Rick Hillegas wrote: Kathey Marsden wrote: Rick Hillegas wrote: What

Re: Proposal for 10.2 release schedule

Rick Hillegas wrote: Daniel John Debrunner wrote: Rick Hillegas wrote: Hi Dan, Thanks for your comments. Some further remarks follow. Regards, -Rick Daniel John Debrunner wrote: Rick Hillegas wrote: Kathey Marsden wrote: Rick Hillegas wrote

Re: Copyright format (was Re: [jira] Updated: (DERBY-1271) Release documentation for JDBC4 release)

? Thanks, -Rick Jean T. Anderson wrote: Rick Hillegas (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-1271?page=all ] Rick Hillegas updated DERBY-1271: - Attachment: derby-1271_copyrights.diff Attaching derby-1271_copyrights.diff. This adjusts

Re: Move 1448, 1449, 1450 , 1452 and 1453 to critical for 10.2?

Hi Kathey, Sounds reasonable to me except for 1450, which Knut Anders has already analyzed. Cheers, -Rick Knut Anders Hatlen wrote: Kathey Marsden [EMAIL PROTECTED] writes: I looked briefly at the compatiblity issues that Deepa filed last week and think the following should be moved

Re: Status of adding BOOLEAN-type

before re-enabling BOOLEAN. My vote would be for (2c) but I don't sense enough enthusiasm for BOOLEAN to justify a major release in the near term. Regards, -Rick Kristian Waagan wrote: Rick Hillegas wrote: Hi Kathey, Right now, I'm planning to back out BOOLEAN before the branch. Hi Rick

Wrapping up coding for 10.2

I hate to be a nudge, but I didn't get a response when I asked this question last week: Do we expect to be done with development for 10.2 by August 10? I expect that the JDBC4 work will have wrapped up by then. Besides the JDBC4 effort, 10.2 is waiting for feature work from Army, Dan, and

Re: Wrapping up coding for 10.2

and assuming a rc1 is created on august 10th it seems pretty aggressive to have all testing and all fixes from that testing in a final rc 2 weeks later. It seems like we needed more time than that for a point release from a stable branch, seems likely that this new branch will take longer. Rick Hillegas

Re: [jira] Created: (DERBY-1459) Early load of Derby driver with JDBC 4.0 autoloading can lead to derby properties not being processed or derby boot time actions consuming resources when a connection

Hi Kathey, Thanks for logging DERBY-1459. That's an excellent description of the problem. I have marked DERBY-1429 as a duplicate of your better-described JIRA. I think that DERBY-1428 is a related problem but I regard it as a separate issue. It describes behavior that exists in the current

Re: Proposal for 10.2 release schedule

Thanks, Rajesh. In your scheme, when should feature work on 10.2 wrap up? I had budgeted 2 weeks between the end of feature work and the first release candidate. Is that overkill? Should we propose that feature work wraps up by, say, July 27? Rajesh Kartha wrote: Rick Hillegas wrote: Last

Re: Proposal for 10.2 release schedule

release candidate generated September 15: Targetted end of voting on release candidates Is this a realistic schedule or is it still too aggressive? Thanks, -Rick Kathy Saunders wrote: Rick Hillegas wrote: Thanks, Rajesh. In your scheme, when should feature work on 10.2 wrap up? I had budgeted 2

Re: Proposal for 10.2 release schedule

Hi Mike, Some responses follow. Regards-Rick Mike Matrigali wrote: Rick Hillegas wrote: Thanks, Kathy. I think I'm getting the message that the following would be an acceptable and more traditional schedule: August 10 : Last feature work commits August 11 : First release candidate

Re: upcoming 10.2 release and regression test failures.

Hi Mike, +1 to cleaning these up for 10.2. I would also add the following bugs: 830 - lang/dcl.sql failures on solaris 1352 - sysinfo locale-specific noise Regards, -Rick Mike Matrigali wrote: There are currently 24 regression test failures listed in jira, I think most apply to the trunk.

Re: [jira] Updated: (DERBY-937) Instability in wisconsin test

Mike Matrigali wrote: Oystein Grovlen - Sun Norway wrote: While it is good that we get this noise out of derbyall, it seems like this fix covers up a problem that we do not quite understand. As far as I have understood, it seems like the optimizer due to some timing issues does not

Revised 10.2 plan for uncoupling the Mustang and Derby release trains

Thanks to everyone for their suggestions and patience. After discussing the JCP issues with many people, including Geir Magnusson and Lance Andersen, I would like to propose the following approach for uncoupling the Mustang and Derby release trains. 1) Lance will publish his proposed final

making a jira filter public

The 10.2 release page contains a link to a JIRA filter I created. How do I make this filter public? Right now, other people are getting a permissions problem when they click on the link. Thanks, -Rick

Re: making a jira filter public

, Rick Hillegas [EMAIL PROTECTED] wrote: The 10.2 release page contains a link to a JIRA filter I created. How do I make this filter public? Right now, other people are getting a permissions problem when they click on the link. When you click Find Issues in the main JIRA menubar

Re: making a jira filter public

Dang. I don't have a Share link in the Operations column. I have View, Edit, Delete, and Add Column Order. Hm. -Rick Andrew McIntyre wrote: On 6/30/06, Rick Hillegas [EMAIL PROTECTED] wrote: Thanks, Andrew. I did stumble on the filter management page. My question is, once I'm on that page

Re: making a jira filter public

Thanks, Kathey. I have put the permlink link into the wiki page as a fallback. Do you know whether this cans the query or the results? Thanks, -Rick Kathey Marsden wrote: Rick Hillegas wrote: Thanks, Andrew. I did stumble on the filter management page. My question is, once I'm on that page

Re: Wiki page for upcoming 10.2 release

Hi Anders, The JIRA pros are pondering this question. In the meantime, I have added another link under the broken one. Could you test-drive the new link and see if it works for you? Thanks, -Rick Anders Morken wrote: Rick Hillegas: In particular, JIRA-pros may want to review whether

Re: Wiki page for upcoming 10.2 release

Thanks, Michelle! Michelle Caisse wrote: The second link works for me. -- Michelle Rick Hillegas wrote: Hi Anders, The JIRA pros are pondering this question. In the meantime, I have added another link under the broken one. Could you test-drive the new link and see if it works for you

Re: making a jira filter public

I respectfully ask for more karma! Michelle Caisse wrote: Whether or not one can see the Share link is a question of karma. Someone of greater karma can grant this privilege to someone of lesser karma. -- Michelle Kathey Marsden wrote: Rick Hillegas wrote: Thanks, Andrew. I did stumble

Re: making a jira filter public

Thanks, Kathey. I have substituted your pessimistic query for my optimistic one and added the critical/blocker query. Kathey Marsden wrote: Rick Hillegas wrote: Thanks, Kathey. I have put the permlink link into the wiki page as a fallback. Do you know whether this cans the query

off list for a week

I'm off on vacation for the week of the 4th. Should be back Monday the 10th. Cheers, -Rick

Re: DERBY-396: Drop Column dependency questions

Hi Bryan, My $0.02 follows. Cheers-Rick Bryan Pendleton wrote: ... a) RESTRICT processing should consider an index on a column to be a dependent object and fail the DROP COLUMN if the column is used in an index? The ANSI spec doesn't provide much guidance here since ANSI doesn't talk

behavior of Statement.getGeneratedKeys()

I would like the community's advice on whether the following Derby behavior is a bug and, if so, whether we would be allowed to change this behavior for 10.2: A) Currently, Derby knows how to automatically generate values for columns of type SMALLINT, INT, and BIGINT. You get this behavior if

Re: behavior of Statement.getGeneratedKeys()

Hi Kathey, My gut feeling is that changing this behavior could affect applications like ij which make formatting decisions based on the JDBC types of returned columns. Kathey Marsden wrote: Rick Hillegas wrote: Before filing a bug on this, I'd like the community's advice: 1

Re: behavior of Statement.getGeneratedKeys()

Daniel John Debrunner wrote: Rick Hillegas wrote: Kathey Marsden wrote: Rick Hillegas wrote: Before filing a bug on this, I'd like the community's advice: 1) Is this a bug? Should Statement.getGeneratedKeys() return a ResultSet whose column has the same type

Re: behavior of Statement.getGeneratedKeys()

Kathey Marsden wrote: Rick Hillegas wrote: 1) Is this a bug? Should Statement.getGeneratedKeys() return a ResultSet whose column has the same type as the underyling autogenerated column? Reading from the JDBC 3.0 and JDBC 4.0 spec it seems clear to me that we are not compliant and if non

Re: behavior of Statement.getGeneratedKeys()

I'd like to try to summarize where I think the discussion stands: 1) Lance, our JDBC expert, has confirmed that this is not a compliance problem. That means this is not a bug. 2) Lance would like to change the behavior of Statement.getGeneratedKeys(). Currently this method always returns a

Re: Language based matching

Hi Kathey, Here is my understanding of how the disabled national string types worked: 1) A national string type used the collation ordering appropriate to the locale of the database. That collation ordering, in turn, was specified by the jdk and could not be overriden. 2) The collation

Fixed issues missing a fix in version marker

There are 85 Fixed Issues with no fix version according to the report linked from http://wiki.apache.org/db-derby/DerbyJiraReports. Presumably all of these are fixed in the mainline and so these improvements will automatically turn up in 10.2 when we cut the branch next month. Is there any

missing components

I just went through the lists of Open issues with no Component and Resolved Issues with no Component linked from http://wiki.apache.org/db-derby/DerbyJiraReports. For most of these, I hazarded a guess about the correct component. However, a few still puzzle me: 625, 1480 - These appear to be

Resolved issues that aren't closed

According to the Resolved issues that are not closed list linked from http://wiki.apache.org/db-derby/DerbyJiraReports, there are 281 issues which have been resolved but which the reporter has not closed. Could everyone spend a half hour reviewing the resolved issues they reported and close

puzzling JIRA report

Hi Kathey, Thanks for compiling the excellent series of JIRA reports at http://wiki.apache.org/db-derby/DerbyJiraReports. I am having some trouble understanding one of these reports: Open Unassigned Issues With Fix Version. When I click on the link, I get 114 issues, 45 of which are

Re: behavior of Statement.getGeneratedKeys()

Hi Kathey, Thanks for your responses. Some replies follow. Regards-Rick Kathey Marsden wrote: Rick Hillegas wrote: I'd like to try to summarize where I think the discussion stands: 1) Lance, our JDBC expert, has confirmed that this is not a compliance problem. That means this is not a bug

Editting JIRA filters

I would like to change the query run by a filter I created. Naively, I did the following: o Clicked Manage to get the list of filters o Clicked Edit to change the filter definition o Made my change to the query, over in the left panel If I run the editted filter, I get results that look

Re: Editting JIRA filters

from current for the new one to rename it with the original name o Delete the temporary filter -- Michelle Rick Hillegas wrote: I would like to change the query run by a filter I created. Naively, I did the following: o Clicked Manage to get the list of filters o Clicked Edit to change

UnsupportedClassVersionError running xa suite under jdk1.3

I'm seeing the following error when I run the xa suite under jdk1.3. This looks like an environmental problem to me. Would appreciate advice on the accepted way to fix my environment for running the tests under jdk1.3. The suite dies trying to load javax.transaction.xa.Xid. This is a class

Re: Language based matching

: Rick Hillegas wrote: 3) The locale-sensitive meaning of , =, and affected the operation of all orderings of national strings, including sorts, indexes, unions, group-by's, like's, between's, and in's. At one point I was keen on re-enabling the national string types. Now I am leaning

Re: Language based matching

Kathey Marsden wrote: Rick Hillegas wrote: [ some interesting stuff about performance] LIKE is going to be a pile of work. I think your LOCALE_MATCHES function will have to duplicate a lot of the code in Derby. At the end of the day, you will replace LIKE with LOCALE_MATCHES and so lose

Re: UnsupportedClassVersionError running xa suite under jdk1.3

Thanks, Myrna, this does the trick! Cheers, -Rick Myrna van Lunteren wrote: On 7/12/06, Rick Hillegas [EMAIL PROTECTED] wrote: I'm seeing the following error when I run the xa suite under jdk1.3. This looks like an environmental problem to me. Would appreciate advice on the accepted way

prioritized 10.2 bug list

Thanks to everyone for helping clean up JIRA and clarify the issues we want to address in 10.2. It would be great if we could march in priority order through the issues listed in the Open 10.2 Issues report at

Re: prioritized 10.2 bug list

, the community might want to make another pass through the untargetted Major bugs and promote some of them to 10.2 ahead of the cruft. Please bear with me. This is my first attempt to manage a release and I welcome your advice about how to make the process more sensible. Kathey Marsden wrote: Rick

Re: sysinfo_api.junit failing in Tinderbox (was: Re: Regression Test Failure! - TinderBox_Derby 422909)

I can confirm this behavior. Fails against jars, succeeds against classtree. Andreas Korneliussen wrote: Andrew McIntyre wrote: The test below that is reported as failing is the new test introduced with DERBY-982, sysinfo_api.junit. This test passes on both my Mac OS X and Windows XP system

10.2.0.4 snapshot available

I have generated a new 10.2 snapshot, which rolls up improvements that accumulated over the last month. Please test-drive it. You can download the snapshot from http://db.apache.org/derby/derby_downloads.html#Snapshot+Jars. For more information, see the wiki page describing the snapshot:

grant/revoke improvements

Hi Satheesh and Mamta, Over the last month you have checked in a lot of great grant/revoke improvements. If there's anything in particular which you want users to test-drive, feel free to list these items on the wiki page that describes the 10.2.0.4 snapshot:

Influencing the standards which govern Derby

I would like to understand how the community influences the standards which govern Derby: 1) SQL - I've been participating in Derby for a year now. Over the past year I don't recall any discussion about a need to change the SQL standard. We have proposed new language in rare cases not covered

Re: grant/revoke improvements

and hope to improve in that arena post 10.2 when there is more breathing time. On 7/19/06, *Rick Hillegas* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi Satheesh and Mamta, Over the last month you have checked in a lot of great grant/revoke improvements. If there's anything

Re: grant/revoke improvements

will not be adding any more support to GRANT/REVOKE beyond this. Satheesh Rick Hillegas wrote: Thanks, Mamta. I have added your concern to the snapshot wiki page. Cheers, -Rick Mamta Satoor wrote: Hi Rick, Thanks for starting out this thread on grant/revoke improvement. One plea I have

Re: JUnit testing moving forward

There are lots of good suggestions in this message. I would add the following: If we're going to consider a new test harness, then we could evaluate using Ant to drive the junit tests. Ant already has an optional junit task for this purpose. Regards, -Rick Daniel John Debrunner wrote: We

Re: Influencing the standards which govern Derby

Thank for the useful discussion. A couple comments follow: Daniel John Debrunner wrote: Rick Hillegas wrote: I would like to understand how the community influences the standards which govern Derby: 1) SQL - I've been participating in Derby for a year now. Over the past year I don't

Re: DOCS: How do I determine which JIRA issues need to be documented in 10.2?

Thanks Laura and Rajesh for raising this issue and composing these filters. I have added the filters to the 10.2 wiki page. Regards, -Rick Rajesh Kartha wrote: Laura Stewart wrote: Hi - I am looking for the best way to filter the JIRA issues to determine which issues need to be documented

remaining 10.2 blocker

Thanks to David for taking DERBY-1377. That leaves one last unassigned blocker: DERBY-936. DERBY-936 is a Documentation issue. Recently, there was some discussion about how to identify outstanding 10.2 documentation issues. This one is definitely at the top of the list. Regards, -Rick

Reference Guide: documenting current SQLStates

The following section of the Reference Guide documents our known SQLStates: Reference Guide-Derby exception messages and SQL states-SQLState and error message reference Do we update this section with each feature release? If so, is there some machinery to automate the drudgery? Thanks,

Re: Reference Guide: documenting current SQLStates

Thanks, Andrew. I have create DERBY-1566 to track this issue. Cheers, -Rick Andrew McIntyre wrote: On 7/21/06, Rick Hillegas [EMAIL PROTECTED] wrote: The following section of the Reference Guide documents our known SQLStates: Reference Guide-Derby exception messages and SQL states

Re: [jira] Commented: (DERBY-1377) Update copyright headers to comply with new ASF policy

We are about 3 weeks away from generating a release candidate which must conform to a new, murky policy. These options occur to me: 1) Generate a release which follows the old policy. I would imagine that the DB PMC would feel bound to reject such a release. 2) Wait for the policy to sort

Re: remaining 10.2 blocker

Hi Kathey, If an issue would cause you to vote -1 on the 10.2 release, please mark the issue as Critical or Blocker. Kathey Marsden wrote: Kathey Marsden wrote: Alternately we could just not muddy the Jira descriptions of these fields and only mark only mark Fix Version 10.2 for an

Re: Are separate JDBC 4.0 versions of the DataSource classes really needed?

Hi Knut Anders, I don't understand part of your experiment. The implementation of createQueryObject() refers to another class, QueryObjectFactory, which was introduced by JDK 1.6. How did EmbeddedDataSource compile with this reference? Thanks, -Rick Knut Anders Hatlen wrote: Hi, I

Hard upgrade issues for 10.2

GRANT/REVOKE requires catalog support and so won't be available to users who soft-upgrade to 10.2. Are there other 10.2 features which will not be available after soft upgrade? Thanks, -Rick

attention all intrepid tech writers

It would be great if one of our tech writers could grab DERBY-1565. This is the rototill of copyrights in Derby documentation and is the highest priority documentation issue right now. Thanks! -Rick

Re: attention all intrepid tech writers

Thanks, Andrew! Hi David and Jean, Do either of you plan to broach with legal-discuss the issues raised by DERBY-1377? Regards, -Rick Andrew McIntyre wrote: On 7/25/06, Rick Hillegas [EMAIL PROTECTED] wrote: It would be great if one of our tech writers could grab DERBY-1565

Re: attention all intrepid tech writers

Thanks, Jean. I wasn't around then. Who took part in those original discussions? Regards, -Rick Jean T. Anderson wrote: Rick Hillegas wrote: Thanks, Andrew! Hi David and Jean, Do either of you plan to broach with legal-discuss the issues raised by DERBY-1377? I think the ones

Re: Hard upgrade issues for 10.2

Thanks, Suresh. I have attached corresponding documentation to DERBY-1594. Regards, -Rick Suresh Thalamati wrote: Rick Hillegas wrote: GRANT/REVOKE requires catalog support and so won't be available to users who soft-upgrade to 10.2. Are there other 10.2 features which

Re: [jira] Commented: (DERBY-765) Valid query fails with ERROR X0A00: The select list mentions column 'A' twice...

Hi Army, Thanks for catching this. No, you're not missing anything. I was experimenting with problem queries and didn't correct this one. Thanks, -Rick Army wrote: Rick Hillegas (JIRA) wrote: WORKAROUND: You can work around this limitation by rewriting your query so that the SELECT

Re: remaining 10.2 blocker

tracking systems: a field which helps engineers figure out what to do next. I would appreciate it if people would use Blocker and Critical to mean, respectively, priority 1 and priority 2. Kathey Marsden wrote: Rick Hillegas wrote: Hi Kathey, If an issue would cause you to vote -1 on the 10.2

Re: remaining 10.2 blocker

Kathey Marsden wrote: Rick Hillegas wrote: . I would appreciate it if people would use Blocker and Critical to mean, respectively, priority 1 and priority 2. Can you put some words around Priority 1 and Priority 2 so I have a better understanding of where to draw the line? How's

Re: remaining 10.2 blocker

the concept of severity. Regards, -Rick Kathey Marsden wrote: Rick Hillegas wrote: Hi Kathey, I think that this is a defect in JIRA. If someone knows how to add a severity field to our bug tracker, that would be great. I notice when I take a Jira report there is an URGENCY option, under custom

Re: remaining 10.2 blocker

Daniel John Debrunner wrote: Rick Hillegas wrote: For 10.2, I want to use the priority field to mean what it means in other bug tracking systems: a field which helps engineers figure out what to do next. I would appreciate it if people would use Blocker and Critical to mean, respectively

Re: remaining 10.2 blocker

Daniel John Debrunner wrote: Rick Hillegas wrote: Thanks, Kathey. I think this does capture what I mean. I think this is your proposal: Priority - Means severity according to the JIRA definitions. Urgency - Has the common-sense meaning of priority, not to be confused with the JIRA sense

Re: remaining 10.2 blocker

, -Rick Kathey Marsden wrote: Rick Hillegas wrote: Thanks, Kathey. I think this does capture what I mean. I think this is your proposal: Priority - Means severity according to the JIRA definitions. Urgency - Has the common-sense meaning of priority, not to be confused with the JIRA sense

Re: [jira] Updated: (DERBY-1554) IDENTITY_VAL_LOCAL() returned value is modified incorrectly by a multi-row INSERT statement.

). I think that the remaining 5 bugs on that list should be marked Urgent and their severity should be downgraded. This will get sorted out after Andrew's hard work. Regards, -Rick Kathey Marsden wrote: Rick Hillegas (JIRA) wrote: Assigning this bug to 10.2 and bumping its priority

Re: Urgency field added

Thanks, Andrew. I can see the Urgency field after I select the Edit action. Before that, however, I can't seem to find Urgency on the bug summary screen. I expected to see it in the upper left hand corner in the Issue Details box, maybe undeneath or above the Priority field. But it's not

Re: Urgency field added

this be improved? Regards, -Rick Andrew McIntyre wrote: On 7/27/06, Rick Hillegas [EMAIL PROTECTED] wrote: Thanks, Andrew. I can see the Urgency field after I select the Edit action. Before that, however, I can't seem to find Urgency on the bug summary screen. I expected to see it in the upper left hand

Re: [jira] Updated: (DERBY-1564) wisconsin.sql test failed in DerbyNet framework, VM for network server got OutOfMemoryError

to be one. Regards, -Rick Kathey Marsden wrote: Rick Hillegas (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-1564?page=all ] Rick Hillegas updated DERBY-1564: - Priority: Major (was: Critical) Since this test runs out of memory, does

Re: Urgency field added

Hi Andrew, And another question: In setting up this filter, I would also like the results to show the Urgency field, so that I can sort on it. This also exceeds my reach. Thanks, -Rick Rick Hillegas wrote: Thanks, Andrew. Now I have another request: I'm trying to set up a filter which

Re: Urgency field added

in this order: Blocker, Urgent, Normal, Low, blank. But the sorter treats Urgency as a string and sorts the issues alphabetically: Blocker, Low, Normal, Urgent, blank. Any workaround here? Thanks! -Rick Andrew McIntyre wrote: On 7/27/06, Rick Hillegas [EMAIL PROTECTED] wrote: And another

can derby-100 be closed?

Hey Mamta, Looks like all the patches for this issue have been committed. Could you confirm whether the issue can be closed? Thanks, -Rick

can we close derby-541?

Hey Andrew, This issue was reopened so that the patch could be ported to 10.1. Can we close this issue now? Thanks, -Rick

  1   2   3   4   5   6   7   8   9   10   >