Skip to content

Development Process

Jump to bottom
Seo-Young Isabelle Hwang edited this page Nov 10, 2015 · 17 revisions

It is the responsibility of JerryScript Maintainers and Reviewers to decide whether submitted code should be integrated into the master branch, returned for revision, or rejected.

Individual developers maintain a local copy of the JerryScript codebase using the git revision control system. Git ensures that all participants are working with a common and up-to-date code base at all times. Each developer works to develop, debug, build, and validate their own code against the current codebase, so that when the time comes to integrate into the master branch of the project, their changes apply cleanly and with a minimum amount of merging effort.

Proposals, Get Answers and Report a Bug via Github Issues

If you have a question about JerryScript code, have trouble any documentation, would like to suggest new feature, or find a bug, review the current JerryScript issues in GitHub, and if necessary, create a new issue.

There are several labels on the Issue. Please choose proper labels on the purpose.

  • bug
  • enhancement : feature enhancement proposal
  • feature request : new feature proposal
  • project announcement : general announcement on the project such as new release, new Maintainer/Reviewer and so on
  • question : any questions on the project
  • discussion

and so on.

Feature development process

The JerryScript Project development process is marked by the following highlights:

  • The feature development process starts with an author discussing a proposed feature with the Maintainers and Reviewers
    • Open the issue with label 'feature request'
  • The Maintainers and Reviewers evaluate the idea, give feedback, and finally approve or reject the proposal.
  • The author shares the proposal with the community via Github issues with 'feature request' label
  • The community provides feedback which can be used by the author to modify their proposal and share it with the community again.
  • The above steps are repeated until the community reaches a consensus according to the Community Guidelines.
  • After a consensus is reached, the author proceeds with the implementation and testing of the feature.
  • After the author is confident their code is ready for integration:
    • The author generates a patch and signs off on their code.
    • The author submits a patch according to the Patch Submission Process.
  • The Maintainers and Reviewers watch the pull request for the patch, test the code, and accept or reject the patch accordingly.
  • After the code passes code review, the Maintainers and Reviewers accept the code(integrated into the master branch), which completes the development process.
  • After a patch has been accepted, it remains the authoring developer's responsibility to maintain the code throughout its lifecycle, and to provide security and feature updates as needed.

Approval Path for PR(Pull Request)

  1. Developer should create/update PR to a given issue or enhancement
  2. If Developer works in a team, then peer-review by a colleague developer should be performed
  3. If peer-review was OK, then Developer should summon the component's maintainer
  4. Maintainer should check the code:
    • make precommit testing is OK (performed automatically)
    • No minor issues (unified implementation style, comments, etc.)
    • No major issues (memory leak, crashes, breakage of ECMA logic, etc.)
  5. If Developer has to rework the solution then goto step 3
  6. If everything is OK, then Maintainer should approve the PR with +1(or LGTM)
    • Code review can be performed by all the members of the project. However only Maintainer can give binding scores.
  7. When the PR get +2(2 LGTM from 2 mainatiners respectively), it should be merged.

Tips on GitHub Issues

  • Check existing JerryScript issues for the answer to your issue. Duplicating an issue slows you and others. Search through open and closed issues to see if the problem you are running into has already been addressed.
  • If necessary, open a new issue.
    • Clearly describe the issue.
      • What did you expect to happen?
      • What actually happened instead?
      • How can someone else recreate the problem?
    • Include system details(such as the hardware, library, and operating system you are using and their versions).
    • Paste error output and logs in the issue or in a Gist(https://gist.github.com/).

For more information about GitHub issues, refer to the GitHub issues guidelines.

Home

About

Development

Documentation

Clone this wiki locally