This is an excellent exposition. Add it to the book?
> On May 29, 2017, at 10:56 AM, Sean Busbey <[email protected]> wrote: > > 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).
