> I just checked the commit, it relates to system property setting, the > fix is quite simple. > I also checked the CI build, it looks like the CI is green[1] > > But my question is this fix was merged into 2.6.x branch for three > weeks ago, why didn't we do the cherry pick it into 2.6.3 release > branch last week? > In Apache projects we maintain 2~3 different branches at the same > time, cherry pick the fix acrocess different branches is a common > practice.
Thanks for the constructive advice and I agree that check and synchronizing between different branches are one important aspect we should pay more attention to. I will bring this discussion to the dev community to attract more committer’s and contributor’s attention later. For this specific issue, since it’s a known UT bug, I tend to fix it in the next release and continue with this RC vote. Saying about UT, I’d like to discuss a little bit more about it here: currently, we have some UTs (3-4 as I know) that are not stable enough themselves, which means they cannot verify features as expected or they may sometimes mis-warn us with failures limited to their own bad logic, and even worse over time, we may be less alert to UT failures. I would suggest we fix these unstable UTs as soon as possible, or at least, if they are not on the schedule now, we should list all these unstable UTs and the possible failures and reasons for failure to reduce the confusion of developers and verifiers. > I know Dubbo team takes almost 1 month to cut this round release, but > it's like a pain of growing. ServiceComb took more than a month to cut > the first around release. We can do the release better if we learn > something from it. Please revisit your release guide and checklist > again, and encourage community to vote -1 once he find something > wrong. The first release was relatively smooth. But in this release, with all the problems encountered, we have learned that there’re still some things lacking in the community to guarantee regular Apache releases with high quality and efficiency. The Dubbo community has worked on with the following aspects to improve that: * How to prepare an Apache release [1]. * The checklist for release candidate [1]. * Release script to automate the release process [2]. [1]. http://dubbo.apache.org/en-us/blog/prepare-an-apache-release.html [2]. https://github.com/apache/incubator-dubbo/blob/2.6.x/release.sh Best regards, Jun > On 6 Sep 2018, at 06:37, Willem Jiang <willem.ji...@gmail.com> wrote: > > I just checked the commit, it relates to system property setting, the > fix is quite simple. > I also checked the CI build, it looks like the CI is green[1] > > But my question is this fix was merged into 2.6.x branch for three > weeks ago, why didn't we do the cherry pick it into 2.6.3 release > branch last week? > In Apache projects we maintain 2~3 different branches at the same > time, cherry pick the fix acrocess different branches is a common > practice. > As someone already observered the test failure in earlier RC, we need > to put some efforts on it (issue tracking) to make sure we fix it in > the next RC. > > I know Dubbo team takes almost 1 month to cut this round release, but > it's like a pain of growing. ServiceComb took more than a month to cut > the first around release. We can do the release better if we learn > something from it. Please revisit your release guide and checklist > again, and encourage community to vote -1 once he find something > wrong. > > [1]https://travis-ci.org/apache/incubator-dubbo/builds/420912788 > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > On Wed, Sep 5, 2018 at 6:39 PM Jerrick Zhu <jerr...@apache.org> wrote: >> >> On Wed, Sep 5, 2018 at 6:10 PM Mark Thomas <ma...@apache.org> wrote: >> >>> On 03/09/18 03:32, Jun Liu wrote: >>> >>> <snip/> >>> >>>> Please vote accordingly: >>>> [X] +1 approve >>>> [ ] +0 no opinion >>>> [ ] -1 disapprove with the reason >>> >>> Notes: >>> ====== >>> >>> Hash and signature match. >>> >>> Source zip matches Git tag (apart from expected differences of >>> .gitignore and Maven wrapper) >>> >>> Builds and all tests except one pass. >>> >>> >>> Issues from previous RC still present in this RC: >>> ================================================= >>> >>> The sha512 hashes are missing the '*' marker that indicates they are >>> hashes for binary files rather than text files. Trivial issue. New RC >>> not required. >>> >>> >>> New issues >>> ========== >>> >>> Tests seem to expect 127.0.0.2 to be a valid IP. If this is the case, >>> consider documenting the requirements to run the tests somewhere obvious >>> in the source tree. Trivial issue. New RC not required. >>> >>> I see the following test failures: >>> Oracle Java 8 update 181 >>> Ubuntu 18.04.1 LTS (fully patched) >>> Maven 3.5.4 >>> >>> This fails consistently for me: >>> >>> ------------------------------------------------------------------------------- >>> Test set: com.alibaba.dubbo.config.AbstractInterfaceConfigTest >>> >>> ------------------------------------------------------------------------------- >>> Tests run: 38, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.119 >>> sec <<< FAILURE! - in com.alibaba.dubbo.config.AbstractInterfaceConfigTest >>> checkApplication1(com.alibaba.dubbo.config.AbstractInterfaceConfigTest) >>> Time elapsed: 0.006 sec <<< FAILURE! >>> junit.framework.ComparisonFailure: expected:<10[0]> but was:<10[]> >>> at >>> >>> com.alibaba.dubbo.config.AbstractInterfaceConfigTest.checkApplication1(AbstractInterfaceConfigTest.java:90) >>> >>> I note that this test has been observed to fail for other community >>> members in earlier RCs. >>> >> >> Yes, it's true, we've fixed it on 2.6.x branch, and will be in next >> release, 2.6.4, but not in 2.6.3. >> >> check the commit: >> https://github.com/apache/incubator-dubbo/commit/93d2eb674b094ee4feee0ef1e46096098c5a22b4 >> >> >>> I can recreate this failure on the command line but not in an IDE. >>> >>> Whether this failure is significant enough to halt the release is >>> something for those more knowledgeable about Dubbo than I to decide. >>> >> >> This is the result of mutual influence of unit test cases, not the >> functional problem. So IMO, this release could be go ahead. What do other >> people think? >> >> >>> >>> >>> Mark >>>
