> Viraj, we have not determined there is a staging repository problem yet. Those files could be “normal” and present in previous RCs and nobody noticed.
Yeah I realized my if condition was not appropriate. +1 stays if we conclude to go ahead with current RC i.e if presence of .asc.asc is not considered a trouble. While we are talking about absence of any other staged repo, I just checked recently released 2.3.3 repo and I see .asc.asc present there: Repository Path: /org/apache/hbase/hbase/2.3.3/hbase-2.3.3-site.xml.asc.asc Uploaded by: vjasani Size: 833 Bytes Uploaded Date: Wed Oct 28 2020 14:51:49 GMT+0530 (India Standard Time) Last Modified: Wed Oct 28 2020 14:51:49 GMT+0530 (India Standard Time) Repository Path: /org/apache/hbase/hbase/2.3.3/hbase-2.3.3.pom.asc.asc Uploaded by: vjasani Size: 833 Bytes Uploaded Date: Wed Oct 28 2020 14:37:37 GMT+0530 (India Standard Time) Last Modified: Wed Oct 28 2020 14:37:37 GMT+0530 (India Standard Time) I definitely used docker based create-release for 2.3.2 and 2.3.3 and did not perform any manual action. On Mon, Dec 7, 2020 at 10:38 PM Andrew Purtell <andrew.purt...@gmail.com> wrote: > Viraj, we have not determined there is a staging repository problem yet. > Those files could be “normal” and present in previous RCs and nobody > noticed. > > > > On Dec 7, 2020, at 5:59 AM, Viraj Jasani <vjas...@apache.org> wrote: > > > > +1 (if staging repository issue is resolved for RC1) > > > > * Signature: ok > > * Checksum : ok > > * Rat check (1.8.0_171): ok > > - mvn clean apache-rat:check > > * Built from source (1.8.0_171): ok > > - mvn clean install -DskipTests > > * CRUD: ok > > * Load 10M rows: ok > > * WebUI: ok > > * Unit tests pass (1.8.0_171): failed > > - mvn package -P runAllTests > > > > > > [ERROR] Failures: > > [ERROR] org.apache.hadoop.hbase.client.TestAsyncTableRSCrashPublish.test > > [ERROR] Run 1: TestAsyncTableRSCrashPublish.test:94 Waiting timed out > after [60,000] msec > > [ERROR] Run 2: TestAsyncTableRSCrashPublish.test:94 Waiting timed out > after [60,000] msec > > [ERROR] Run 3: TestAsyncTableRSCrashPublish.test:94 Waiting timed out > after [60,000] msec > > [ERROR] Run 4: TestAsyncTableRSCrashPublish.test:94 Waiting timed out > after [60,000] msec > > > > Failure seems to have some env issue as branch-2 nightly > > looks good for this test. > > > > > >> On 2020/12/04 00:04:37, Andrew Purtell <apurt...@apache.org> wrote: > >> Please vote on this Apache hbase release candidate, hbase-2.4.0RC1 > >> > >> The VOTE will remain open for at least 72 hours. > >> > >> [ ] +1 Release this package as Apache hbase 2.4.0 > >> [ ] -1 Do not release this package because ... > >> > >> The tag to be voted on is 2.4.0RC1: > >> > >> https://github.com/apache/hbase/tree/2.4.0RC1 > >> > >> The release files, including signatures, digests, as well as CHANGES.md > >> and RELEASENOTES.md included in this RC can be found at: > >> > >> https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/ > >> > >> Customarily Maven artifacts would be available in a staging repository. > >> Unfortunately I was forced to terminate the Maven deploy step after > >> the upload ran for more than four hours and my build equipment > >> needed to be relocated, with loss of network connectivity. This RC has > >> been delayed long enough. A temporary Maven repository is not a > >> requirement for a vote. I will retry Maven deploy tomorrow. I can > >> promise the artifacts for this RC will be staged in Apache Nexus and > >> ready for release well ahead of the earliest possible time this vote > >> can complete. > >> > >> Artifacts were signed with the apurt...@apache.org key which can be > found > >> in: > >> > >> https://dist.apache.org/repos/dist/release/hbase/KEYS > >> > >> The API compatibility report for this RC can be found at: > >> > >> > >> > https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/api_compare_2.4.0RC1_to_2.3.0.html > >> > >> The changes are mostly added methods, which conform to the compatibility > >> guidelines for a new minor release. There is one change to the public > >> Region interface that alters the return type of a method. This is > >> equivalent to a removal then addition and can be a binary compatibility > >> problem. However to your RM's eye the change looks intentional and is > >> part of an API improvement project, and a compatibility method is not > >> possible here because Java doesn't consider return type when deciding if > >> one method signature duplicates another. > >> > >> To learn more about Apache HBase, please see > >> > >> http://hbase.apache.org/ > >> > >> Thanks, > >> Your HBase Release Manager > >> > -- Thanks, Viraj
