THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
Page History
| Table of Contents |
|---|
Apache Way
Apache Way, Apache Con (Slides)
JIRA Process
| Info | ||
|---|---|---|
| ||
The JIRA handling process outlined below should be followed in absolutely all cases, without exceptions, regardless of the ticket complexity. |
...
| Info | ||
|---|---|---|
| ||
New contributors should register an account at https://issues.apache.org/jira/secure/Dashboard.jspa and send out an email to the project's dev mailing list (subscribe) with a request for contributors permissions. Committers should handle this request and grant contributor access to a new community member. |
Getting Started
- Easy tickets to get started with Apache Ignite: open tickets with `newbie` label
- All other issues: Ignite Jira
Tickets and Versions
Tickets are picked up by community members from a pool of unassigned and unscheduled tickets.
...
The following page contains information on upcoming releases: Release Planning.
Ticket Creation
- Every JIRA ticket should be sufficiently described. Avoid filing tickets with title only and without description.
- If possible, please provide a reproducer or runnable test for Bug tickets.
- If there is a discussion pertaining to the ticket, the ticket should have a link to the dev mailing list.
Working on a ticket
- Anyone in the community may start working on any Unassigned ticket.
- (OPTIONAL) It is recommended to clarify the relevance and correctness of the ticket with the community before doing actual implementation. To do this, you can write an email to the dev mailing list and wait for an answer (please do not forget to subscribe to the list first).
- Before beginning working on a ticket, you should assign the ticket to yourself.
- Move the ticket to
IN PROGRESSstate. - If necessary, add comments describing the design decisions or approach you plan to take.
Documenting a ticket
If the changes implemented under the ticket require changes in user documentation, create a related documentation ticket (add "Documentation" to the Component field) and provide a reasonable amount of details in the ticket's description. The information provided in the ticket should be sufficient for any contributor to start working on it. If there is no need to change user documentation, uncheck the Docs Required flag. The Docs Required flag is used to filter out the tickets that require documentation so that our documentation is always up to date.
Review Process and Maintainers
- Ignite employs both Review-Then-Commit processes.
- Please consult to Review Checklist to understand how tickets are reviewed and what rules to follow.
...
Any change should be reviewed by a contributor and passed to a committer (who may or may not be the same as the main reviewer) for merging.
Submitting for Review
- Attach Pull Request URL to ticket (see instructions at Workflow)
- Add comment describing what has been implemented.
- Run tests using Run All... TeamCity suite. Validate that all tests have passed using TeamCity bot. It allows checking that no new non-flaky tests have failed, and posting the confirmation ("TC green visa") to the ticket.
- Move ticket to
PATCH AVAILABLEstate. - If you know a contributor who should review this ticket, you should mention them directly:
...
- Otherwise, please open a thread on the dev mailing list describing the change and asking for review.
- If there is no review activity after a week has passed, try picking another reviewer or bumping the dev mailing list thread.
Reviewing a Ticket
- Make sure that your patch satisfies Review Checklist rules.
- Each comment should be started with [~username] to guarantee proper notification.
- The reviewer may suggest improvements. It is recommended to leave a comment on the ticket in addition to PR comments. This helps other contributors to identify that patch may need improvement.
- Patch author may implement those improvements or discuss the best course of action with the reviewer.
- The reviewer should add comment like "looks good to me" (LGTM) once the review successfully finished.
- When the ticket is reviewed, any committer may merge it.
Closing a Ticket
- Once the ticket has passed all the reviews and has no additional comments, the committer should apply the latest patch and push it to the master branch.
- The committer should comment on the ticket stating that the patch has been applied to the master.
- File release notes for this ticket, and unset Release Notes Required flag.
- Set fixVersion field to target release, usually the next unreleased version.
- Move ticket to RESOLVED state.
GIT workflow
Setting up:
- You need to fork an Apache Ignite mirror on GitHub.
- Make a local copy of your Apache Ignite mirror fork. Your remote origin will refer to 'https://github.com/<your_github_uname>/ignite'.
You will need to update a local master sometimes (to merge to your development branches sometimes). How to do it:
Add remote for Apache Ignite mirror (you need to do it once)
git remote add upstream https://github.com/apache/ignite
Each time when you want to update your local master do the following:
Code Block git pull upstream git checkout master
...
| Info | ||
|---|---|---|
| ||
Note: Existing pull requests should be updated instead of the creation of new ones, when possible. |
Information for committers
In addition to contributors configuration, committers need to have one more remote repo - for working with Apache Git repo. It can be added like this:
...
- Checks that you don't have any uncommitted changes.
- Checks you are one master branch and the master branch is up-to-date.
- Updates local master from Apache git repo.
- Fetches pull request to a local branch:
git fetch upstream pull/<id>/head:pull-<id>-head- Saves an author and a comment of the last commit at pull-<id>-head.
- Merges from the new branch to master:
git merge --squash pull-<id>-head
- Ask you about a custom comment or using the saved comment.
- Commit to local master. The script automatically sign-off a commit and add "Fixes #<id>." suffix to comment (It will close the pull request, see https://help.github.com/articles/closing-issues-via-commit-messages/):
git commit --author=“<saved_author>" -s -m “<comment> - Fixes #<id>.”
Now, you will have one commit at master with all changes from the pull-request. Changes can be reviewed again. If you accept all changes and want to push it, do next:
git push apache master
Create a Ticket Branch (only for committers)
Whenever working on bigger features, committers can also create 'ready to be reviewed' branch ignite-XXXX, where XXXX is the number of the JIRA ticket.
...
The branch should be deleted on branch merged to master or issue canceled. Committers are in charge of deleting their branches.
Appendix A. Components and their maintainers
| Component | Maintainers | |
|---|---|---|
| Ignite Core (the rest of internals not covered below) | ||
| PME | ||
| Rebalance | ||
| Affinity | ||
| PDS | ||
| Encryption | ||
| MVCC (obsolete) | ||
| Transactions | ||
| Marshalling (Binary, Optimized, JDK) | ||
| Discovery & Communication SPIs | ||
| Ignite Compute API | ||
| Ignite Services API | ||
| Ignite SQL & Text Queries & JDBC | ||
| Ignite Continuous Queries | ||
| Machine Learning/Deep Learning (ml, TensorFlow, sub-modules in ml) | ||
| Build System / Releases | ||
| TeamCity Bot | ||
| Spark Integration | ||
| .NET API | ||
| C++ API | ||
| Other thin clients (Python, Node.js, PHP, etc) | ||
| ODBC | ||
| JDBC | ||
| Streamers (JMS, Flume, Kafka, etc.) | ||
| Docker, Mesos, YARN integration | ||
| AWS, Google Compute Engine, JClouds integration | ||
| Visor Console | ||
| WebSession & WebSession Filter | ||
...
Overview
Content Tools
Apps