User Tools

Site Tools


iotivity_features_branches_and_release_process

This is an old revision of the document!


(Proposed) Feature, Branch and Release Process

Overview

IoTivity is adopting a process to marshal contributions of any size into the project. This document will walk you through the process of suggesting a feature, design with review, implementation with review, acceptance and scheduling for release. There are milestones for your feature as well as milestones for release that are covered on this page.

Feature Milestones

Features come in many sizes and implications. The requirements for each are a little different. Trivial features are those that only affect a handful of files, easily expressed in a very short paragraph and have limited impact on the larger body of code. Minor and major features are larger, require a design and design review and may impact the entire stack operation. The process for each is covered here.

Where does it start?

It starts with an idea. A potential contributor should start by bringing their feature to the iotivity-dev mailing list. In this forum, the idea can be vetted and the size and scope can be determined. If the feature is trivial, such as adding a new property to a resource, it may be listed (see below). If more detailed discussion is needed, the contributor should capture the feature as a design document or design notes on the wiki so that it can go under review.

TODO: Add link to an example

Feature (Design) under Review

After the design is posted to the wiki and the posting has been announced on the mailing list, it is considered under review. At this time discussion should continue on the mailing list and the author should continue to edit the design on the wiki based on feedback. Once all comments have been addressed, the feature may be listed (see below)

TODO: Need to define time under review. Silent consent allowed?

Feature Listing

Listing your feature just means that it is tracked in Jira. When ready, the contributor or requester of the feature should create a Jira ticket (enhancement) to track the feature. Jira will be used to track who is working on it and to provide status. Jira allows “child” tickets to allow reporting of progress. Using this feature is highly encouraged. If there is an associated design document, it is recommended that the URI to the design document to be included on the Jira ticket AND that the design document refer to the Jira ticket(s).

If the feature requester is also going to be the contributor, it is recommended that they assign the Jira ticket to themselves.

TODO: Add link to Jira site.

Feature in Progress

Once there is a Jira ticket and a contributor is ready to implement, the contributor should request a feature branch from the domain maintainer. When requesting, be sure to provide the Jira ticket number so the maintainer can determine whether the feature is ready (ie. design covered the feature and has been reviewed if needed). Again, it is best practice to note the branch name on the Jira ticket as well as post progress to the Jira ticket comments.

Feature Complete

To be feature complete, a contributor must meet the following criteria:

  • Code complete
  • Unit tests
  • Sample application written, if needed
  • Validated in build environment
  • Testing complete
  • Documentation updated, if needed

At this point, the contributor may push to gerrit for community review. The contributor should be sure the invite the domain maintainer and any other members that may have participated in the design discussions. After addressing all of the concerns of the maintainer, the maintainer will give the review a +2 and submit the code.

TODO: Talk about the merge process from the feature branch to the master branch.

Release Milestones

The upcoming schedule can be found here.

Regarding Defects

iotivity_features_branches_and_release_process.1433446337.txt.gz · Last modified: 2015/06/04 19:32 by Patrick Lankswert