hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: [DISCUSS] Checking release candidates
Date Tue, 30 May 2017 16:20:32 GMT
Great note Sean.

Some rah-rah below.

On Mon, May 29, 2017 at 10:56 AM, Sean Busbey <busbey@apache.org> wrote:

> ...
> 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 ;) )
I concur.

Trying and voting release candidates, or voting on threads like the
concurrent 'Merge AMv2' vote thread are good ways to note your interest in
being a committer or becoming PMC.


> 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).

Yeah, above belongs in the book.

Good stuff,

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message