diff --git a/.nojekyll b/.nojekyll new file mode 100644 index 000000000..e69de29bb diff --git a/404.html b/404.html new file mode 100644 index 000000000..36f40a42d --- /dev/null +++ b/404.html @@ -0,0 +1,516 @@ + + + +
+ + + + + + + + + + + + + + +In the interest of fostering an open and welcoming environment, we as +contributors and maintainers pledge to making participation in our project and +our community a harassment-free experience for everyone, regardless of age, body +size, disability, ethnicity, sex characteristics, gender identity and expression, +level of experience, education, socio-economic status, nationality, personal +appearance, race, religion, or sexual identity and orientation.
+Examples of behavior that contributes to creating a positive environment +include:
+Examples of unacceptable behavior by participants include:
+Project maintainers are responsible for clarifying the standards of acceptable +behavior and are expected to take appropriate and fair corrective action in +response to any instances of unacceptable behavior.
+Project maintainers have the right and responsibility to remove, edit, or +reject comments, commits, code, wiki edits, issues, and other contributions +that are not aligned to this Code of Conduct, or to ban temporarily or +permanently any contributor for other behaviors that they deem inappropriate, +threatening, offensive, or harmful.
+This Code of Conduct applies both within project spaces and in public spaces +when an individual is representing the project or its community. Examples of +representing a project or community include using an official project e-mail +address, posting via an official social media account, or acting as an appointed +representative at an online or offline event. Representation of a project may be +further defined and clarified by project maintainers.
+Instances of abusive, harassing, or otherwise unacceptable behavior may be +reported by contacting the project team. All +complaints will be reviewed and investigated and will result in a response that +is deemed necessary and appropriate to the circumstances. The project team is +obligated to maintain confidentiality with regard to the reporter of an incident. +Further details of specific enforcement policies may be posted separately.
+Project maintainers who do not follow or enforce the Code of Conduct in good +faith may face temporary or permanent repercussions as determined by other +members of the project's leadership.
+This Code of Conduct is adapted from the Contributor Covenant, version 1.4, +available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
+For answers to common questions about this code of conduct, see +https://www.contributor-covenant.org/faq
+ + + + + + + + + + + + + +Our project welcomes external contributions. If you have an itch, please feel +free to scratch it.
+To contribute code or documentation, please submit a pull request. You can get started with open issues with the label - good first issue. +Before embarking on a more ambitious contribution, please quickly get in touch with us via raising an issue.
+Note: We appreciate your effort, and want to avoid a situation where a contribution +requires extensive rework (by you or by us), sits in backlog for a long time, or +cannot be accepted at all!
+If you would like to implement a new feature, please raise an issue, +before sending a pull request so the feature can be discussed. This is to avoid +you wasting your valuable time working on a feature that the project developers +are not interested in accepting into the code base.
+If you would like to fix a bug, please raise an issue, before sending a +pull request so it can be tracked.
+The project maintainers use LGTM (Looks Good To Me) in comments on the code +review to indicate acceptance. A change requires LGTMs from two of the +maintainers of each component affected.
+For a list of the maintainers, see the MAINTAINERS.md page.
+Each source file must include a license header for the Apache +Software License 2.0. Using the SPDX format is the simplest approach. +e.g.
+ +We have tried to make it as easy as possible to make contributions. This +applies to how we handle the legal aspects of contribution. We use the +same approach - the Developer's Certificate of Origin 1.1 (DCO) - that the Linux® Kernel community +uses to manage code contributions.
+We simply ask that when submitting a patch for review, the developer +must include a sign-off statement in the commit message.
+Here is an example Signed-off-by line, which indicates that the +submitter accepts the DCO:
+ +To include Signed-off-by message automatically, set the git config as, +
+and include flag -s | --sign-off
when you commit a change to your local git repository, for example
Please note the many useful options of the make command, as shown by using make help
, that will take care of manual steps that would have been needed for tasks such as building, publishing, setting up or testing transforms in most directories.
Coding style as enforced by pre-commit
.
David Wood - dawood@us.ibm.com
+Boris Lublinsky - blublinsky@ibm.com
+Revital Eres - eres@il.ibm.com
+ + + + + + + + + + + + + +Releases are created from the main repository branch using the version
+numbers, including an intermediate version suffix,
+defined in .make.versions
.
+The following points are important:
.make.versions
contains the version to be used when publishing the next release. .make.versions
is changed, make set-versions
should be run from the top of the repo.make set-versions
should ONLY be used from the top of the repo when .make.versions
changes.scripts/release-branch.sh
script automates creation of a new release branch and tag and version numbers in .make.versions
scripts/release-branch.sh
. Creating the release involves
+release-notes.md
to list major/minor changesrelease-branch.sh
).Each is discussed below.
+Make a dummy release on github (see below) to get a listing of all commits. +Use this to come up with the items. +Commit this to the main branch so it is ready for including in the release branch.
+The scripts/release-branch.sh
is currently run manually to create the branch and tags as follows:
releases/vX.Y.Z
from the main branch where X.Y.Z
are defined in .make.versionsvX.Y.Z
branch for PR'ing back into the releases/vX.Y.Z
branch. vX.Y.Z
branch .make.version
file. make set-versions
..pending-version-change/vX.Y.Z
branch for PR'ing back into the main branch.pending-version-change/vX.Y.Z
branchdev0
in .make.versions
.To double-check the version that will be published from the release, +
+This will print for example, 1.2.3. +To run the script from the top of the repo:
+ +After running the script, you should
+1. Create a pull request from branch vX.Y.Z
into the releases/vX.Y.Z
branch, and merge.
+2. Use the github web UI to create a git release and tag of the releases/vX.Y.Z
branch
+3. Create a pull request from branch pending-version-change/vX.Y.Z
into the main branch, and merge.
After running the release-branch.sh
script, to create tag vX.Y.Z
and branch releases/vX.Y.Z
+and PRing/merging vX.Y.Z
into releases/vX.Y.Z
.
+1. Go to the releases page.
+1. Select Draft a new release
+1. Select target branch releases/vX.Y.Z
+1. Select Choose a tag
, type in vX.Y.Z, click Create tag
+1. Press Generate release notes
+1. Add a title (e.g., Release X.Y.Z)
+1. Add any additional relese notes.
+1. Press Publish release
After creating the release and tag on github:
+.../data-prep-kit
)make show-version
to see the version that will be publishedmake build
make publish
(See credential requirements below)For docker registry publishing, the following environment variables/credentials are needed:
+.make.defaults
To publish to pypi, the credentials in ~/.pypirc
file (let us know if there is a way to do
+this with environment variables).
+See pypi for details.