Versions Compared

Old Version 26

changes.mady.by.user Anton Vinogradov

Saved on

compared with

New Version 27

changes.mady.by.user Anton Vinogradov

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Info
titleIMPORTANT

The JIRA handling process outlined below should be followed in absolutely all cases, without exceptions, regardless of the ticket complexity.

Ticket Creation

  • Every JIRA ticket should be sufficiently described. 
  • There should not be any tickets with title only and without description. 
  • If there is a discussion pertaining to the ticket, the ticket should have a link to the dev list.

Beginning Work

  • Anyone in the community can start working on any unassigned ticket
  • Before beginning working on a ticket, you should assign the ticket to yourself.
  • Move the ticket to IN PROGRESS state.
  • If necessary, add comments describing the design decisions or approach you plan to take.

JIRA issues are grouped by version field, which is an intended version of the product feature gets merged to.

Tickets are picked up by community members from a pool of unassigned and unscheduled tickets after discussion on project's dev list. Assigning tickets to a version contributor helps others to understand what will be included in next release.

Ticket Creation

  • Every JIRA ticket should be sufficiently described. 
  • There should not be any tickets with title only and without description. 
  • If there is a discussion pertaining to the ticket, the ticket should have a link to the dev list.

Beginning Work

  • Anyone in the community can start working on any unassigned ticket
  • Before beginning working on a ticket, you should assign the ticket to yourself.
  • Move the ticket to IN PROGRESS state.
  • If necessary, add comments describing the design decisions or approach you plan to take.

Commit Then Commit Then Review (CTR)

  • Ignite employs Commit-Then-Review (CTR) process.
  • It is up to a committer to decide whether a change should need a review or not. 
  • Any change that touches code or test, whether reviewed or not, must have full TeamCity CI test suite pass.
  • As a guideline, trivial changes, like updates to documentation or tests, etc. should not need a review prior to committing, and often can be made directly in the master branch.
  • It is strongly recommended to have non-trivial changes reviewed by at least one other committer.
Info
titleMaster Branch
 Ignite "master" branch should always be release-ready. Please avoid any commits or merges to the "master" branch unless the whole TeamCity CI suite has passed.

Submitting For Review

  • Create and attach Attach a patch, pull request url or branch name (see instructions hereinstructions at Contribution ways)
  • Add comment describing what has been implemented.
  • Move ticket to PATCH AVAILABLE state.
  • If there is a community member who you think should do the review, optionally assign the ticket to that person.

...

Normally, project repo should contain only master branch, very few branches for ongoing releases and commiter's branches ready to be reviewed. Committers and PMC members are in charge to make everyone follow this rule.

Contributors should attach patch to JIRA issue and change issue's status to Patch Available.  After CI passes (http://204.14.53.153/overview.html), issue should be reassigned to committer for review and incorporation of the changes to sprint branch. See CI part below for more information about patch creation and patch validation. 

Committers may create a patch, a pull request, or create a branch ignite-1234, where 1234 is the number of the JIRA ticket.

JIRA Issues

JIRA issues are grouped by version field, which is an intended version of the product feature gets merged to.

Tickets are picked up by community members from a pool of unassigned and unscheduled tickets after discussion on project's dev list. Assigning tickets to a version contributor helps others to understand what will be included in next release.

CI

's branches ready to be reviewed. Committers and PMC members are in charge to make everyone follow this rule.

Contributors should attach patch to JIRA issue and change issue's status to Patch Available.  After CI passes (TeamCity is used for Continuous Integration. It is located here - http://204.14.53.153/overview.html.

Patch creation

), issue should be reassigned to committer for review and incorporation of the changes to sprint branch. See CI part below for more information about patch creation and patch validation. 

Committers may create a patch, a pull request, or create a branchSee How to Contribute page.

Release Process

Instructions on how to build source and binary releases can be found at IGNITE_PROJECT_ROOT/DEVNOTES.txt. Please see Ignite Release Instructions section.

...

3. Ticket Branch (only committers)

 It is legal to create 'ready to be reviewed' branch ignite-XXXX, where XXXX is the number of the JIRA ticket.

...