You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@openwhisk.apache.org by mr...@apache.org on 2018/04/04 19:20:17 UTC
[incubator-openwhisk-release] 01/01: Clean up and refactor README
contents with Rel. Mgr. tutorial.
This is an automated email from the ASF dual-hosted git repository.
mrutkowski pushed a commit to branch add-status
in repository https://gitbox.apache.org/repos/asf/incubator-openwhisk-release.git
commit beac81925fadd2b913d571d4cdb59f491260493b
Author: Matt Rutkowski <mr...@us.ibm.com>
AuthorDate: Wed Apr 4 14:20:04 2018 -0500
Clean up and refactor README contents with Rel. Mgr. tutorial.
---
README.md | 57 +++++++++++++++++++++++++++----------------
docs/tutorial.md | 73 ++++++++++++++++++++++++++++++++++++++++----------------
2 files changed, 89 insertions(+), 41 deletions(-)
diff --git a/README.md b/README.md
index 20f0bc1..942b27e 100644
--- a/README.md
+++ b/README.md
@@ -17,26 +17,43 @@
-->
# OpenWhisk Graduate and Release Management
+
[](http://www.apache.org/licenses/LICENSE-2.0)
[](https://travis-ci.org/apache/incubator-openwhisk-release)
-This project is responsible for the Release Management of OpenWhisk projects, by automating the processes of verifying
-the source code, building & deploying OpenWhisk, packaging the source code and binaries, publishing the artifacts to
-the specified online directories, etc. OpenWhisk is a serverless event-based programming service and currently an Apache
-Incubator project. The ultimate goal of this project is to guarantee the compliance with the Apache release requirements
-for OpenWhisk projects.
+The primary goal of this project is to provide the Apache OpenWhisk project's Release Managers the automation needed to guarantee a release complies with both the Apache Software Foundation's (ASF) [Release Creation Process](http://www.apache.org/dev/release-publishing.html) and [Release Policy](http://www.apache.org/legal/release-policy.html).
+
+Specifically, this repository provides Release Management of all designated Apache OpenWhisk project repositories, by automating:
+- Verification of the source code LICENSE and NOTICE files
+- Building & deploying the OpenWhisk platform
+- Running Build Verification Tests (BVT)
+- Generating CHANGELOGs for each project repository (since last release)
+- Packaging and signing source code (compressed archives) and binaries
+- publishing the artifacts to the approved Apache directories
+
+all in accordance with Apache guidelines.
+
+## Release Process Methodology
+
+This project uses Travis CI as the automated integration build tool to streamline the release process of Apache OpenWhisk. Stages can be applied to build different jobs, which are able to run either in sequential or parallel. Artifacts can be shared across different jobs by using the cache feature in Travis, as different jobs run on different virtual machines.
-We use Travis CI as the automated integration build tool to streamline the release process of OpenWhisk. Stages can be
-applied to build different jobs, which are able to run either in sequential or parallel. Artifacts can be shared across
-different jobs by using cache in Travis, as different jobs run on different virtual machines.
+## Release publishing
-# Instruction to use OpenWhisk Release
+Staged candidate releases of Apache OpenWhisk artifacts are published to the approved staging repository path under Apache with all required PGP singatures:
+- https://dist.apache.org/repos/dist/dev/incubator/openwhisk/
+Once candidates are approved, in accordance with required release processes and policies, their artifacts can be moved from the staging path to the approved release path:
+- https://dist.apache.org/repos/dist/release/incubator/openwhisk/.
+
+# Instructions for Release Managers
+
+## Release Manager Tutorial
As a release manger of OpenWhisk, please visit [OpenWhisk Release tutorial](docs/tutorial.md).
-# How to release an Apache project
+## How to release an Apache project
## Release Approval
+
Apache requires a minimum of three positive votes and more positive than negative votes MUST be cast, in order to release.
Release manager of OpenWhisk sends a release note to the OpenWhisk mailing for votes, and opens the mail for 72 hours.
We can create JIRA issue for this release and close it when the requirement is met and ready for release. This step can
@@ -44,16 +61,17 @@ be done manually by the release manager, beyond the scope of this project.
An example of the release note can be found at the following link: [example of release note](https://github.com/apache/cordova-coho/blob/master/docs/coho-release-process.md).
-## Artifacts
-We need to package the source code and the complied binaries separately. Each of them should be signed cryptographically.
-The package of source code needs to provide the installation script for users to deploy a full OpenWhisk environment.
-We target to implement this step in Travis build.
+## Artifact requirements
+Artifacts for project repository source code and any compiled binaries are packaged separately with each artifact being signed cryptographically.
+
+Source code needs to provide the installation script for users to deploy a full OpenWhisk environment. We target to implement this step in Travis build.
+
+## Licensing requirements
-## Licensing
All the source code has to be compliant with Apache Licensing Policy, by adding the LICENSE file, NOTICE file to each
repository and the release package, and adding Licensing headers to each source code file. Please visit [License_Compliance](docs/license_compliance.md) for detailed information.
-## Release distribution
+## Release distribution requirements
We need to upload all artifacts to project’s subdirectory in Apache channel. This step needs to be implemented in Travis build.
# Specifications to implement the above release process
@@ -63,9 +81,8 @@ following page.
- [General Specification](docs/general_spec.md)
-# Reference
+# References
[Apache release policy](http://www.apache.org/legal/release-policy.html)
-# Important Note
-There can be some missing steps in the release process described above for Apache projects, which will be implemented in
-future. We welcome any comments and contributions.
+# Notes
+This projecy is still "in development" with many steps still in the process of being automated and brought into compliance. We welcome any reviews, comments or contributions to help us complete and improve any part of the process.
diff --git a/docs/tutorial.md b/docs/tutorial.md
index 963705b..6ca2ec4 100644
--- a/docs/tutorial.md
+++ b/docs/tutorial.md
@@ -18,12 +18,53 @@
# Release Manager Tutorial
-This project offers the release manager of OpenWhisk two modes to release OpenWhisk projects: manual mode and automated mode.
-Manual mode makes sure that the release manager can download the source code of this repository, and go through the release
-process by running scripts sequentially on a local machine, to push the artifacts into the staging directory and eventually
-move them into the Apache release directory. Automated mode provides the release manager another option to walk through the
-Apache release process by kicking off the Travis job to run the scripts. A release manager can choose either way to publish
-the artifacts in the staging directory and the Apache release directory.
+## Key requirements for producing releases
+
+As a Release Manager, please know that most of these requirements are addressed via the release process automation provided in this project; however, some steps are manual. Regardless of automation, it is good to understand all the key considerations and requirements that a release manager is ultimately responsible for.
+
+### Licensing requirements
+
+All the source code has to be compliant with Apache Licensing Policy, by adding the LICENSE file, NOTICE file to each repository and the release package, and adding Licensing headers to each source code file. Please visit [License_Compliance](docs/license_compliance.md) for detailed information.
+
+### Artifact requirements Artifacts for project repository source code and any compiled binaries are packaged separately with each artifact being signed cryptographically.
+
+Source code needs to provide the installation script for users to deploy a full OpenWhisk environment. We target to implement this step in Travis build.
+
+### Release distribution requirements
+
+These steps have been **automated** for the Release Manager.
+
+All release artifacts must be uploaded to project’s designated subdirectory in the Apache distribution channel (i.e., [https://dist.apache.org/repos/dist/](https://dist.apache.org/repos/dist/)).
+
+Specifically, the Apache OpenWhisk project has paths to publish both candidate (staged) releases:
+- [https://dist.apache.org/repos/dist/dev/incubator/openwhisk/](https://dist.apache.org/repos/dist/dev/incubator/openwhisk/)
+
+and the approved release path:
+- [https://dist.apache.org/repos/dist/release/incubator/openwhisk/](https://dist.apache.org/repos/dist/release/incubator/openwhisk/).
+
+
+### Release Approval
+
+These steps are **manual** and must be performed by the Release Manager.
+
+Apache requires a minimum of three positive votes and more positive than negative votes MUST be cast, in order to release.
+
+-The Release manager for Apache OpenWhisk sends a release note to the OpenWhisk mailing for votes, and opens the mail for 72 hours.
+- **TBD** We can create JIRA issue for this release and close it when the requirement is met and ready for release. **TODO** further document discrete steps/requirements community agrees upon.
+
+### Create Release notes
+
+An example of the release note can be found at the following link: [example of release note](https://github.com/apache/cordova-coho/blob/master/docs/coho-release-process.md).
+
+# Release Process
+
+This project offers the Apache OpenWhisk Release Manager two modes to release OpenWhisk projects:
+- Manual mode and
+- Automated mode.
+
+_Manual mode_ makes sure that the release manager can download the source code of this repository, and go through the release process by running scripts sequentially on a local machine, to push the artifacts into the staging directory and eventually move them into the Apache release directory.
+
+_Automated mode_ provides the release manager another option to walk through the Apache release process by kicking off the Travis job to run the scripts. A release manager can choose either way to publish the artifacts in the staging directory and the Apache release directory.
## Manual mode of Release Process
1. [Preparing for a release](prepare_release.md) - how to prepare OpenWhisk projects for a release
@@ -44,22 +85,12 @@ the artifacts in the staging directory and the Apache release directory.
## Automated mode of Release Process
-The release manager can take full advantage of Travis CI to implement the release process. The only manual step is to
-configure the release information, by editing the configuration file _config.json_. Please refer to [edit configuration file](pick_up_source_code.md#edit-the-configuration-file)
-for the information able to be configured.
+The release manager can take full advantage of Travis CI to implement the release process. The only manual step is to configure the release information, by editing the configuration file _config.json_. Please refer to [edit configuration file](pick_up_source_code.md#edit-the-configuration-file) for the information able to be configured.
-* **PR-based Travis build**: the Travis build triggered by a pull request. Each time the file config.json is ready, release
-manager can submit a pull request to the master branch of OpenWhisk release repository. Based on the result of the Travis build,
-we know whether the configurations in config.json can be used as a candidate to release. This type of Travis build will
-download the source code, generate the artifacts, sign the artifacts, install the OpenWhisk services and run the test cases.
+* **PR-based Travis build**: the Travis build triggered by a pull request. Each time the file config.json is ready, release manager can submit a pull request to the master branch of OpenWhisk release repository. Based on the result of the Travis build, we know whether the configurations in config.json can be used as a candidate to release. This type of Travis build will download the source code, generate the artifacts, sign the artifacts, install the OpenWhisk services and run the test cases.
-* **Push-based Travis build**: the Travis build triggered by a push into master branch. When a PR with new configurations
-is accepted, the release manager can merge it to kick off this type of Travis build. On top of the tasks done by PR-based
-Travis build, it will upload the artifacts into the staging directory.
+* **Push-based Travis build**: the Travis build triggered by a push into master branch. When a PR with new configurations is accepted, the release manager can merge it to kick off this type of Travis build. On top of the tasks done by PR-based Travis build, it will upload the artifacts into the staging directory.
-* **Tag-based Travis build**: the Travis build triggered by git tag. After the vote succeeds in the community, we decide to
-move the artifacts from the staging directory to the Apache release directory. This type of Travis build is responsible
-for this task.
+* **Tag-based Travis build**: the Travis build triggered by git tag. After the vote succeeds in the community, we decide to move the artifacts from the staging directory to the Apache release directory. This type of Travis build is responsible for this task.
-In summary, the release process of OpenWhisk is the process of developing the configuration file _config.json_ for a
-certain release.
+In summary, the release process of OpenWhisk is the process of developing the configuration file _config.json_ for a certain release.
--
To stop receiving notification emails like this one, please contact
mrutkowski@apache.org.