Great note Sean. Some rah-rah below.
On Mon, May 29, 2017 at 10:56 AM, Sean Busbey <[email protected]> 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
