Derby
  1. Derby
  2. DERBY-4806

SysinfoCPCheckTest fail on different Windows platforms on 10.6.2.0 release candidate

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 10.6.1.0
    • Fix Version/s: 10.5.3.1, 10.6.2.2, 10.7.1.1
    • Component/s: Test
    • Labels:
      None
    • Environment:
      Windows
    • Urgency:
      Normal
    • Bug behavior facts:
      Regression Test Failure

      Description

      For the preliminary platform testing [1] Kathey, Dag and Lily
      have seen SysinfoCPCheckTest fail on different Windows platforms(XP and Windows 7) when
      run as part of suitesAll.

      [1] http://wiki.apache.org/db-derby/TenSixTwoPlatformTesting

      Thanks to Myrna points out that it could relate to DERBY-3771.

      1. rjall.out
        587 kB
        Lily Wei
      2. DERBY-4806-3b.diff
        0.8 kB
        Lily Wei
      3. DERBY-4806-3.diff
        6 kB
        Lily Wei
      4. DERBY-4806-2.diff
        7 kB
        Lily Wei
      5. DERBY-4806-1.diff
        5 kB
        Lily Wei

        Issue Links

          Activity

          Hide
          Lily Wei added a comment -

          This is the output when running on Windows 7 against db-derby-10.6.2.0-bin

          Show
          Lily Wei added a comment - This is the output when running on Windows 7 against db-derby-10.6.2.0-bin
          Hide
          Kathey Marsden added a comment -

          This definitely seems related to having derbyTesting.jar in a different directory and running in the context of a suite. I can reproduce with just tools._Suite, where the output of the sysinfo command is:

          cp command: -cp org.apache.derbyTesting.functionTests.tests.tools.SysinfoCPCheck
          Test.class
          linenumber=6
          0:FOUND IN CLASS PATH:
          1:
          2:
          3:NOT FOUND IN CLASS PATH:
          4:
          5: user-specified class (org.apache.derbyTesting.functionTests.tests.tools.Sys
          infoCPCheckTest)
          7: (org.apache.derbyTesting.functionTests.tests.tools.SysinfoCPCheckTest not
          found.)

          If I run the test stand alone it is ok:
          cp command: -cp org.apache.derbyTesting.functionTests.tests.tools.SysinfoCPCheck
          Test.class
          linenumber=6
          0:FOUND IN CLASS PATH:
          1:
          2: user-specified class (org.apache.derbyTesting.functionTests.tests.tools.Sys
          infoCPCheckTest)
          3: C:\cygwin\svn4\10.6\jars\testjar\derbyTesting.jar
          4:
          5:
          7:SUCCESS: All Derby related classes found in class path.
          null
          8:null

          The test itself hasn't changed since the 10.6 branch was made and the only sysinfo change was to remove JCC so I am not sure why this problem is occurring.

          Show
          Kathey Marsden added a comment - This definitely seems related to having derbyTesting.jar in a different directory and running in the context of a suite. I can reproduce with just tools._Suite, where the output of the sysinfo command is: cp command: -cp org.apache.derbyTesting.functionTests.tests.tools.SysinfoCPCheck Test.class linenumber=6 0:FOUND IN CLASS PATH: 1: 2: 3:NOT FOUND IN CLASS PATH: 4: 5: user-specified class (org.apache.derbyTesting.functionTests.tests.tools.Sys infoCPCheckTest) 7: (org.apache.derbyTesting.functionTests.tests.tools.SysinfoCPCheckTest not found.) If I run the test stand alone it is ok: cp command: -cp org.apache.derbyTesting.functionTests.tests.tools.SysinfoCPCheck Test.class linenumber=6 0:FOUND IN CLASS PATH: 1: 2: user-specified class (org.apache.derbyTesting.functionTests.tests.tools.Sys infoCPCheckTest) 3: C:\cygwin\svn4\10.6\jars\testjar\derbyTesting.jar 4: 5: 7:SUCCESS: All Derby related classes found in class path. null 8:null The test itself hasn't changed since the 10.6 branch was made and the only sysinfo change was to remove JCC so I am not sure why this problem is occurring.
          Hide
          Kathey Marsden added a comment -

          The tools suite passes with security manager turned off: -Djava.security.policy="<NONE>"

          The underlying exception that causes sysinfo -cp to report the org.apache.derbyTesting.functionTests.tests.SysinfoCPCheckTest.class is not found.

          I am having a bit of trouble tracking down what changed in 10.6.2.0 and do not understand
          why the test passes when run stand alone, but see a couple problems here.
          1) The underlying exception is not reported by sysinfo -cp. It just catches any Throwable and then reports the class as not found, so it should report the excepiton that caused the problem.
          2) In this case the class really should be found.

          The only 10.6.2.0 change I see for sysinfo is to remove JCC and I don't really see how that could have caused this. I tried with the 10.6.1.0 release and it does not seem to
          have the problem.

          I think this might take a bit of time to figure out exactly I think the short story is that this might be some sort
          of regression in 10.6.2.0, but I don't think it is that serious that it should hold up the next release candidate.

          java.security.AccessControlException: Access denied (java.io.FilePermission C:\c
          ygwin\svn4\10.6\jars\testjar\derbyTesting.jar read)
          at java.lang.Throwable.<init>(Throwable.java:67)
          at java.security.AccessControlException.<init>(AccessControlException.ja
          va:62)
          at java.security.AccessController.checkPermission(AccessController.java:
          68)
          at java.lang.SecurityManager.checkPermission(SecurityManager.java:533)
          at java.lang.SecurityManager.checkRead(SecurityManager.java:872)
          at java.io.File.exists(File.java:731)
          at java.io.Win32FileSystem.canonicalize(Win32FileSystem.java:358)
          at java.io.File.getCanonicalPath(File.java:559)
          at org.apache.derby.impl.tools.sysinfo.Main.formatURL(Main.java:1230)
          at org.apache.derby.impl.tools.sysinfo.Main.access$200(Main.java:87)
          at org.apache.derby.impl.tools.sysinfo.Main$7.run(Main.java:1131)
          at java.security.AccessController.doPrivileged(AccessController.java:202
          )
          at org.apache.derby.impl.tools.sysinfo.Main.getFileWhichLoadedClass(Main
          .java:1113)
          at org.apache.derby.impl.tools.sysinfo.Main.tryMyClasspath(Main.java:669
          )
          at org.apache.derby.impl.tools.sysinfo.Main.trySomeClasspaths(Main.java:
          619)
          at org.apache.derby.impl.tools.sysinfo.Main.useMe(Main.java:547)
          at org.apache.derby.impl.tools.sysinfo.Main.getClasspathInfo(Main.java:3
          94)
          at org.apache.derby.impl.tools.sysinfo.Main.main(Main.java:130)
          at org.apache.derby.tools.sysinfo.main(sysinfo.java:53)
          at org.apache.derbyTesting.functionTests.tests.tools.SysinfoCPCheckTest.
          testClassPathChecker(SysinfoCPCheckTest.java:130)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
          java:48)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
          sorImpl.java:25)
          at java.lang.reflect.Method.invoke(Method.java:600)
          at junit.framework.TestCase.runTest(TestCase.java:154)
          at junit.framework.TestCase.runBare(TestCase.java:127)
          at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:
          109)
          at junit.framework.TestResult$1.protect(TestResult.java:106)
          at junit.framework.TestResult.runProtected(TestResult.java:124)
          at junit.framework.TestResult.run(TestResult.java:109)
          at junit.framework.TestCase.run(TestCase.java:118)
          at junit.framework.TestSuite.runTest(TestSuite.java:208)
          at junit.framework.TestSuite.run(TestSuite.java:203)
          at junit.framework.TestSuite.runTest(TestSuite.java:208)
          at junit.framework.TestSuite.run(TestSuite.java:203)
          at junit.textui.TestRunner.doRun(TestRunner.java:116)
          at junit.textui.TestRunner.start(TestRunner.java:172)
          at junit.textui.TestRunner.main(TestRunner.java:138)

          I

          Show
          Kathey Marsden added a comment - The tools suite passes with security manager turned off: -Djava.security.policy="<NONE>" The underlying exception that causes sysinfo -cp to report the org.apache.derbyTesting.functionTests.tests.SysinfoCPCheckTest.class is not found. I am having a bit of trouble tracking down what changed in 10.6.2.0 and do not understand why the test passes when run stand alone, but see a couple problems here. 1) The underlying exception is not reported by sysinfo -cp. It just catches any Throwable and then reports the class as not found, so it should report the excepiton that caused the problem. 2) In this case the class really should be found. The only 10.6.2.0 change I see for sysinfo is to remove JCC and I don't really see how that could have caused this. I tried with the 10.6.1.0 release and it does not seem to have the problem. I think this might take a bit of time to figure out exactly I think the short story is that this might be some sort of regression in 10.6.2.0, but I don't think it is that serious that it should hold up the next release candidate. java.security.AccessControlException: Access denied (java.io.FilePermission C:\c ygwin\svn4\10.6\jars\testjar\derbyTesting.jar read) at java.lang.Throwable.<init>(Throwable.java:67) at java.security.AccessControlException.<init>(AccessControlException.ja va:62) at java.security.AccessController.checkPermission(AccessController.java: 68) at java.lang.SecurityManager.checkPermission(SecurityManager.java:533) at java.lang.SecurityManager.checkRead(SecurityManager.java:872) at java.io.File.exists(File.java:731) at java.io.Win32FileSystem.canonicalize(Win32FileSystem.java:358) at java.io.File.getCanonicalPath(File.java:559) at org.apache.derby.impl.tools.sysinfo.Main.formatURL(Main.java:1230) at org.apache.derby.impl.tools.sysinfo.Main.access$200(Main.java:87) at org.apache.derby.impl.tools.sysinfo.Main$7.run(Main.java:1131) at java.security.AccessController.doPrivileged(AccessController.java:202 ) at org.apache.derby.impl.tools.sysinfo.Main.getFileWhichLoadedClass(Main .java:1113) at org.apache.derby.impl.tools.sysinfo.Main.tryMyClasspath(Main.java:669 ) at org.apache.derby.impl.tools.sysinfo.Main.trySomeClasspaths(Main.java: 619) at org.apache.derby.impl.tools.sysinfo.Main.useMe(Main.java:547) at org.apache.derby.impl.tools.sysinfo.Main.getClasspathInfo(Main.java:3 94) at org.apache.derby.impl.tools.sysinfo.Main.main(Main.java:130) at org.apache.derby.tools.sysinfo.main(sysinfo.java:53) at org.apache.derbyTesting.functionTests.tests.tools.SysinfoCPCheckTest. testClassPathChecker(SysinfoCPCheckTest.java:130) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:48) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:600) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java: 109) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.textui.TestRunner.doRun(TestRunner.java:116) at junit.textui.TestRunner.start(TestRunner.java:172) at junit.textui.TestRunner.main(TestRunner.java:138) I
          Hide
          Kathey Marsden added a comment -

          Another point for improvement is that the call to:

          result = new File(filename).getCanonicalPath().replace('/', File.separatorChar);

          in sysinfo.Main.formatURL() should be wrapped in a privilege block. Again this code dates back to 2006 so does not explain why this problem shows up now.

          Show
          Kathey Marsden added a comment - Another point for improvement is that the call to: result = new File(filename).getCanonicalPath().replace('/', File.separatorChar); in sysinfo.Main.formatURL() should be wrapped in a privilege block. Again this code dates back to 2006 so does not explain why this problem shows up now.
          Hide
          Lily Wei added a comment -

          Sysinfo has option on -cp command for anyClass.class. However, it does have the argument option to be testing to print derbyTesting.jar. Should it have the option for testing to remember its path and print out its version?

          Show
          Lily Wei added a comment - Sysinfo has option on -cp command for anyClass.class. However, it does have the argument option to be testing to print derbyTesting.jar. Should it have the option for testing to remember its path and print out its version?
          Hide
          Lily Wei added a comment -

          Even though derbyTesting.jar is not in the same directory as derbyrun.jar, Main.useme should still use trysomeclasspath(..) and use trymyClassPath to find the right derbyTesting.jar which should print similar message as the following:
          $ sysinfo -cp org.apache.derbyTesting.functionTests.tests.tools.SysinfoCPCheckT
          est.class
          FOUND IN CLASS PATH:

          user-specified class (org.apache.derbyTesting.functionTests.tests.tools.Sysin
          foCPCheckTest)
          C:\derby3\trunk\testjar\derbyTesting.jar

          SUCCESS: All Derby related classes found in class path.

          If we got 'SUCCESS: All Derby related classes found in class path.', we have no JIRA-4806. And, when trace inside the debugger with single SysinfoCPCheckTest test, this is exactly what happened. Main.trymyclassPath(...) with org.apache.derbyTesting.functionTests.tests.tools.SysinfoCPCheckTest.class return SUCCESS:All Derby related classes found in class path. However, somehow, when running tools._Suite, the result will have failure on org.apache.derbyTesting.functionTests.tests.tools.SysinfoCPCheckTest not found. Print out anything in Main.formatURL or Main.trymyclassPath will result in SysinfoCPCheckTest failure cause unexpected string from` Sysinfo -cp org.apache.derbyTesting.functionTests.tests.tools.SysinfoCPCheckTest.class`. Any other way on print out more meaningful tracing information will be helpful.
          Originally, I though due to taking out db2driver (db2jcc.jar) change which change the overall output and cause this to happen. So, I make the necessary change to clean up jcc related test DERBY-4806-1.diff patch. Please review the changes.
          However, this patch is still getting the same failure if derbyTesting.jar is in different directory than derbyrun.jar.

          Show
          Lily Wei added a comment - Even though derbyTesting.jar is not in the same directory as derbyrun.jar, Main.useme should still use trysomeclasspath(..) and use trymyClassPath to find the right derbyTesting.jar which should print similar message as the following: $ sysinfo -cp org.apache.derbyTesting.functionTests.tests.tools.SysinfoCPCheckT est.class FOUND IN CLASS PATH: user-specified class (org.apache.derbyTesting.functionTests.tests.tools.Sysin foCPCheckTest) C:\derby3\trunk\testjar\derbyTesting.jar SUCCESS: All Derby related classes found in class path. If we got 'SUCCESS: All Derby related classes found in class path.', we have no JIRA-4806. And, when trace inside the debugger with single SysinfoCPCheckTest test, this is exactly what happened. Main.trymyclassPath(...) with org.apache.derbyTesting.functionTests.tests.tools.SysinfoCPCheckTest.class return SUCCESS:All Derby related classes found in class path. However, somehow, when running tools._Suite, the result will have failure on org.apache.derbyTesting.functionTests.tests.tools.SysinfoCPCheckTest not found. Print out anything in Main.formatURL or Main.trymyclassPath will result in SysinfoCPCheckTest failure cause unexpected string from` Sysinfo -cp org.apache.derbyTesting.functionTests.tests.tools.SysinfoCPCheckTest.class`. Any other way on print out more meaningful tracing information will be helpful. Originally, I though due to taking out db2driver (db2jcc.jar) change which change the overall output and cause this to happen. So, I make the necessary change to clean up jcc related test DERBY-4806 -1.diff patch. Please review the changes. However, this patch is still getting the same failure if derbyTesting.jar is in different directory than derbyrun.jar.
          Hide
          Lily Wei added a comment -

          DERBY-4806-2.diff is the patch that run fine if derbyTesitng.jar is in different directory than derbyrun.jar.

          If we are running the tools._Suite, Main.formatURL(...) failed to return the name of the file for derbyTesting.jar if it is located in different directory than derbyrun.jar. I remember for the discussion of Derby-4715 https://issues.apache.org/jira/browse/DERBY-4715?focusedCommentId=12887533&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12887533

          It is best to just use URL.toString() to extract the file information. That is what I did here. However, I think it should handle Encoding for UTF8 as in formatURL in this case. Any suggestion is welcome.
          This patch also take out db2jcc.jar related code for Main.jar and SysinfoCPCheckTest.jar. The code is ready for review. I am running the test now.

          Show
          Lily Wei added a comment - DERBY-4806 -2.diff is the patch that run fine if derbyTesitng.jar is in different directory than derbyrun.jar. If we are running the tools._Suite, Main.formatURL(...) failed to return the name of the file for derbyTesting.jar if it is located in different directory than derbyrun.jar. I remember for the discussion of Derby-4715 https://issues.apache.org/jira/browse/DERBY-4715?focusedCommentId=12887533&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12887533 It is best to just use URL.toString() to extract the file information. That is what I did here. However, I think it should handle Encoding for UTF8 as in formatURL in this case. Any suggestion is welcome. This patch also take out db2jcc.jar related code for Main.jar and SysinfoCPCheckTest.jar. The code is ready for review. I am running the test now.
          Hide
          Knut Anders Hatlen added a comment -

          + try

          { + // DERBY-4806 Should use UTF-8 according to + // http://www.w3.org/TR/html40/appendix/notes.html#non-ascii-chars + // to get the string of the file name + return URLDecoder.decode(result.toString(), "UTF-8"); + }

          catch (UnsupportedEncodingException e)

          { + // All JVMs are required to support UTF-8. + return Main.getTextMessage("SIF01.W", e.getMessage()); + }

          The comment correctly states that all JVMs are required to support UTF-8, so the UnsupportedEncodingException is never supposed to happen. Most other places we just ignore the UnsupportedEncodingException if we know it can't happen, or have a THROWASSERT in a debug block for extra sanity checking. Not a big issue, but I'd prefer that we didn't add a new message (SIF01.W) for something that should never happen, so that we save the translators some unnecessary work. What about just returning e.getMessage() in the case of UnsupportedEncodingException here, similar to what you did with IOException in formatURL()?

          Show
          Knut Anders Hatlen added a comment - + try { + // DERBY-4806 Should use UTF-8 according to + // http://www.w3.org/TR/html40/appendix/notes.html#non-ascii-chars + // to get the string of the file name + return URLDecoder.decode(result.toString(), "UTF-8"); + } catch (UnsupportedEncodingException e) { + // All JVMs are required to support UTF-8. + return Main.getTextMessage("SIF01.W", e.getMessage()); + } The comment correctly states that all JVMs are required to support UTF-8, so the UnsupportedEncodingException is never supposed to happen. Most other places we just ignore the UnsupportedEncodingException if we know it can't happen, or have a THROWASSERT in a debug block for extra sanity checking. Not a big issue, but I'd prefer that we didn't add a new message (SIF01.W) for something that should never happen, so that we save the translators some unnecessary work. What about just returning e.getMessage() in the case of UnsupportedEncodingException here, similar to what you did with IOException in formatURL()?
          Hide
          Lily Wei added a comment -

          Thank you so much, Knut. I though having detail error message is always beneficial to customers. However, I agree this message is rarely happened so doing translate work for this is a lot. I change return to e.getMessage() and put it in DERBY-4806-3.diff patch. It did passed tools._Suite with derbyTesting.jar in different directory than derbyrun.jar. Please review the code. I am running more tests now.

          Show
          Lily Wei added a comment - Thank you so much, Knut. I though having detail error message is always beneficial to customers. However, I agree this message is rarely happened so doing translate work for this is a lot. I change return to e.getMessage() and put it in DERBY-4806 -3.diff patch. It did passed tools._Suite with derbyTesting.jar in different directory than derbyrun.jar. Please review the code. I am running more tests now.
          Hide
          Knut Anders Hatlen added a comment -

          Thanks for making this change, Lily. I haven't studied the other changes in the patch, so I cannot say if this is the correct fix for the problem. But then I'm not able to reproduce it in my environment, so I hope someone who sees the problem can comment on that.

          Show
          Knut Anders Hatlen added a comment - Thanks for making this change, Lily. I haven't studied the other changes in the patch, so I cannot say if this is the correct fix for the problem. But then I'm not able to reproduce it in my environment, so I hope someone who sees the problem can comment on that.
          Hide
          Kathey Marsden added a comment -

          Hi Lily,

          I think the patch is fine. When you check in please put DERBY-4597 to remove JCC in your checkin comment, so it gets linked to that issue. Generally it is a good idea to separate fixes, but I think it is fine to combine here since it is already done and both will likely be backported anyway.

          Show
          Kathey Marsden added a comment - Hi Lily, I think the patch is fine. When you check in please put DERBY-4597 to remove JCC in your checkin comment, so it gets linked to that issue. Generally it is a good idea to separate fixes, but I think it is fine to combine here since it is already done and both will likely be backported anyway.
          Hide
          Lily Wei added a comment -

          Thanks to Kathey and Knut for reviewing the code. And, Kathey for giving me more helpful tips in turn of how better improving the coding style. It would be better to separate DERBY-4597 fix in the future. I check-in 1002682 after running tests for Suites.All and derbyall. I am back porting to 10.6 and 10.5

          Show
          Lily Wei added a comment - Thanks to Kathey and Knut for reviewing the code. And, Kathey for giving me more helpful tips in turn of how better improving the coding style. It would be better to separate DERBY-4597 fix in the future. I check-in 1002682 after running tests for Suites.All and derbyall. I am back porting to 10.6 and 10.5
          Hide
          Knut Anders Hatlen added a comment -

          Hi Lily,

          derbyrunjartest failed in the tinderbox after the check-in. Looks like a canon must be updated. Here's the diff:

                          • Diff file derbyall/derbytools/derbyrunjartest.diff
              • Start: derbyrunjartest jdk1.6.0_18 derbyall:derbytools 2010-09-29 19:02:34 ***
                4 del
                < USAGE: java org.apache.derby.tools.sysinfo -cp [ [ embedded ][ server ][ client] [ db2driver ] [ tools ] [ anyClass.class ] ]
                4a4
                > USAGE: java org.apache.derby.tools.sysinfo -cp [ [ embedded ][ server ][ client] [ tools ] [ anyClass.class ] ]
                Test Failed.
              • End: derbyrunjartest jdk1.6.0_18 derbyall:derbytools 2010-09-29 19:02:36 ***
          Show
          Knut Anders Hatlen added a comment - Hi Lily, derbyrunjartest failed in the tinderbox after the check-in. Looks like a canon must be updated. Here's the diff: Diff file derbyall/derbytools/derbyrunjartest.diff Start: derbyrunjartest jdk1.6.0_18 derbyall:derbytools 2010-09-29 19:02:34 *** 4 del < USAGE: java org.apache.derby.tools.sysinfo -cp [ [ embedded ][ server ][ client] [ db2driver ] [ tools ] [ anyClass.class ] ] 4a4 > USAGE: java org.apache.derby.tools.sysinfo -cp [ [ embedded ][ server ][ client] [ tools ] [ anyClass.class ] ] Test Failed. End: derbyrunjartest jdk1.6.0_18 derbyall:derbytools 2010-09-29 19:02:36 ***
          Hide
          Lily Wei added a comment -

          Sorry! Add DERBY-4806-3b.diff which has the updated canon file for derbyrunjartest.java. Please review it! Thanks!

          Show
          Lily Wei added a comment - Sorry! Add DERBY-4806 -3b.diff which has the updated canon file for derbyrunjartest.java. Please review it! Thanks!
          Hide
          Lily Wei added a comment -

          back port to 10.6 and 10.5 with 1003070, 1003071

          Show
          Lily Wei added a comment - back port to 10.6 and 10.5 with 1003070, 1003071
          Hide
          Knut Anders Hatlen added a comment -

          [bulk update] Close all resolved issues that haven't been updated for more than one year.

          Show
          Knut Anders Hatlen added a comment - [bulk update] Close all resolved issues that haven't been updated for more than one year.

            People

            • Assignee:
              Lily Wei
              Reporter:
              Lily Wei
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development