Hi folks! I've recently a VOTE for the next upstream 1.2.z release. I figured that's a good time to restart a discussion around what we mean as a community when we talk about checking on these things.
I usually expect that checking on a release candidate for a maintenance release (1.y.z for some z > 0) will take me about a half hour of actively looking at things. If you're not yet on the PMC and would like to work towards PMC (or committer!) status, please also take the time to cast a non-binding vote. Voting on releases is the single most important way to demonstrate "acting like a PMC member" and the easiest way to gain recognition from the community. (or at least from this one PMC member, natch ;) ) Here's a link to the thread in the archive: https://s.apache.org/hbase-1.2.6-rc0-vote-thread Here's the brief section of the HBase community guide on what we mean when we say "try out a release candidate": http://hbase.apache.org/book.html#hbase.rc.voting (Note that this guide has some obvious gaps. JIRAs that point out those gaps and/or patches to clarify things once someone has explained the gap to you are another great way to get visibility in the community. :) ) Since this is a maintenance release, the level of scrutiny will generally be lower than a minor or major release. For some context on the effort others have put into prior 1.2.z maintenance releases, check out the responses on some VOTE threads: * https://s.apache.org/hbase-1.2.5-rc0-vote * https://s.apache.org/hbase-1.2.4-rc1-vote * https://s.apache.org/hbase-1.2.4-rc0-vote * https://s.apache.org/hbase-1.2.3-rc0-vote For a maintenance release, the short version is: * Do the published artifacts match the publishes signature and checksum files? (so downstream can see that they have the right thing after downloading) * Does the signer of the artifacts match someone in the project's KEYS file? (so downstream can tell that the artifacts come from the project in an official capacity) * Does the source artifact correspond to a well defined point in the source repository? (so downstream can tell where a given part of the source came from) * Can the binary artifacts be created from the source artifact? (so downstream doesn't have to rely on the convenience artifacts) * Does the release meet our compatibility promises? (so downstream can treat upgrading as low risk) * Can the source artifact pass unit tests? (so downstream can be confident there aren't new regressions) * Can the binary artifact be used to run an HBase instance? (even if just a standalone instance) The first four are a matter of ASF policy. The last few I'd argue are established norms within HBase (based on looking at what folks in prior releases checked before voting).
