> Just a quick note for binary release, it only includes the dubbo > jars. It could be more convenience for the end user if we can include > the third party dependencies jars in the binary release.
Yes, this is a point that I have seen some people have also put out in the community, but sadly, there’s still no progress now. I will file an issue to track it later. BTW, the vote has lasted for 72+ hours and we have received 3 +1(binding) votes. I will announce the pass of this vote in a new email and continue to release. Best regards, Jun > On 9 Sep 2018, at 14:56, Willem Jiang <willem.ji...@gmail.com> wrote: > > Sorry, I just got some time back to this thread. > I just went through the dev discussion of the dubbo and found out > dubbo community are planning the next release cut by discussion the > bug fix list first. I'm sure we could do it better in the next > release. > > Here are my +1 for this vote. > I can build the code from source. > The artifacts were signed with right key. > > For the UT test error, is only related to system property setting > which will not effect the end user. > Just a quick note for binary release, it only includes the dubbo > jars. It could be more convenience for the end user if we can include > the third party dependencies jars in the binary release. > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > On Fri, Sep 7, 2018 at 9:57 AM Jun Liu <liu...@apache.org> 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. >> >> 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 >>>>> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org >
