hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <andrew.purt...@gmail.com>
Subject Re: [DISCUSS] Checking release candidates
Date Mon, 29 May 2017 18:15:41 GMT
This is an excellent exposition. Add it to the book?

> On May 29, 2017, at 10:56 AM, Sean Busbey <busbey@apache.org> 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
> 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).

View raw message