Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
MIME-Version: 1.0
Sender: saint.ack@gmail.com
In-Reply-To: <pony-5c0191c5bda2836af1cb87878694cfbf1db676c8-d5bb3dad6a2d7338754a113f42432b1bd40b802f@dev.hbase.apache.org>
References: <pony-5c0191c5bda2836af1cb87878694cfbf1db676c8-d5bb3dad6a2d7338754a113f42432b1bd40b802f@dev.hbase.apache.org>
From: Stack <stack@duboce.net>
Date: Tue, 30 May 2017 09:20:32 -0700
Message-ID: <CADcMMgH51cD0vKu7++1odOZO-PC9E-HSZ4WKCkpuyS4E738zjA@mail.gmail.com>
Subject: Re: [DISCUSS] Checking release candidates
To: HBase Dev List <dev@hbase.apache.org>
Content-Type: multipart/alternative; boundary="94eb2c14eef4cc8e510550c02ee5"
archived-at: Tue, 30 May 2017 16:20:41 -0000

--94eb2c14eef4cc8e510550c02ee5
Content-Type: text/plain; charset="UTF-8"

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,
S

--94eb2c14eef4cc8e510550c02ee5--