Yocto Project Design and Development Process - Revision history

Song: /* Point Release Process */

2013-09-10T21:45:44Z

Point Release Process

← Older revision		Revision as of 21:45, 10 September 2013
Line 432:		Line 432:
	A point release is a minor release such as 1.0.x. Point releases are necessary to address the following:		A point release is a minor release such as 1.0.x. Point releases are necessary to address the following:

	~~# Security updates~~
	# Issues building on current Linux distributions.		# Issues building on current Linux distributions.
	# ~~Issues that existed in previous~~ release ~~and have significant impact to users.~~		# fix critical bugs and security issues (CVEs) for the first 6 months after release
			# fix security issues for the first year after release

	===Maintainers ===		===Maintainers ===

Song: /* Major Release Checkpoints */

2013-05-31T16:46:41Z

Major Release Checkpoints

← Older revision		Revision as of 16:46, 31 May 2013
Line 88:		Line 88:


	* Kernel version (major kernel version) and tool chain (including libc’s) major version lock: 6 weeks before release ~~code freeze~~.		* Kernel version (major kernel version) and tool chain (including libc’s) major version lock: 6 weeks before release feature complete.
	* Final stable kernel update before code freeze.		* Final stable kernel update before code freeze.
	* Package update ongoing, target set and checked for each milestone.		* Package update ongoing, target set and checked for each milestone.

Song: /* Milestone Review */

2013-02-25T19:28:13Z

Milestone Review

← Older revision		Revision as of 19:28, 25 February 2013
Line 191:		Line 191:

	These reviews should normally be done when features are completed for the milestone, and feedback and changes will be handled in the next milestone. When it’s really necessary to review features when they are partially completed, there is the risk that we may have to adjust the milestone plan in the middle of the milestone for reviewed features, which should be avoided unless it is really necessary.		These reviews should normally be done when features are completed for the milestone, and feedback and changes will be handled in the next milestone. When it’s really necessary to review features when they are partially completed, there is the risk that we may have to adjust the milestone plan in the middle of the milestone for reviewed features, which should be avoided unless it is really necessary.

			==Milestone Testing==

			During the first stabilization week of a milestone, the first release candidate build (RC1) will be generated. QA will first run a weekly test on RC1. Once the weekly test is done, QA will notify (via email) the program manager. The program manager will lead a decision making process with the bug triage team:

			1. If there's nothing major that should block the release, the program manager will notify QA to continue with a full-pass test on RC1.
			2. If there is any release blocker, we will fix them and prepare for RC2.

			After the decision is made, the program manager will notify QA. If RC2 needs to be generated, we always run a full pass testing on RC2.

	==Milestone Retrospective==		==Milestone Retrospective==

Song: /* The Goal */

2013-01-30T21:19:05Z

The Goal

← Older revision		Revision as of 21:19, 30 January 2013
Line 25:		Line 25:
	** Setup goals for medium+ and medium features for the release.		** Setup goals for medium+ and medium features for the release.
	** We encourage the team to schedule medium+ features into each milestone also.		** We encourage the team to schedule medium+ features into each milestone also.

			===Feature Priority ===

	The priorities of each feature are defined below:		The priorities of each feature are defined below:

Song: /* The Goal */

2013-01-30T21:18:05Z

The Goal

← Older revision		Revision as of 21:18, 30 January 2013
Line 28:		Line 28:
	The priorities of each feature are defined below:		The priorities of each feature are defined below:

	* High: crucial ~~items~~		* High: major customer requirement we have to deliver for the release. These are items crucial to system functionality, user experience and project adoption.
	* Medium+: ~~compared with medium items,~~ these are more important items that ~~need more attention due~~ to ~~their bigger~~ impact to system functions, build system, etc.		* Medium+: these are more important items that we should strive to deliver for the release. They have significant impact to system functions, build system, etc.
	* Medium: important items		* Medium: important items we should keep track of and try to deliver.
	* Low: nice to have items		* Low: nice to have items

Song: /* Feature Status Update */

2013-01-17T19:32:22Z

Feature Status Update

@@ Line 346: / Line 346: @@
 ==Feature Status Update==
-The status owner of the feature is responsible to update the feature bug whiteboard with the current phase of the feature once the feature goes into a different stage. The following lists the status owner of each stage:
+The status owner of the feature is responsible to update the feature bug status. Yocto Project Bugzilla defines all the development phases in the status field. Owners shall use the status field to update the status weekly.
-# Specification: architects, engineering manager, business program manager, developers, feature author
+The whiteboard can be used for more detailed status information, for example the percentage completed.
 ==Iterations==

Song: /* Estimation */

2012-08-03T18:42:34Z

Estimation

← Older revision		Revision as of 18:42, 3 August 2012
Line 388:		Line 388:
	In Yocto Project, each feature should have effort estimation done during the following processes:		In Yocto Project, each feature should have effort estimation done during the following processes:

	# '''Release planning''': In this process, we don’t know much about the design and implementation details of a feature. But a rough estimation will make us start thinking about how much effort it could involve and help with the overall release planning, especially for ~~priority 1 (P1)~~ features. Otherwise, we pretty much have no idea what features can be done at what time.		# '''Release planning''': In this process, we don’t know much about the design and implementation details of a feature. But a rough estimation will make us start thinking about how much effort it could involve and help with the overall release planning, especially for high features. Otherwise, we pretty much have no idea what features can be done at what time.
	# '''Design & Design Review''': When a feature is in design and design review stage, details of the design and implementation will be worked out. At this stage, we can update the feature with a better estimation. This will help us schedule our work and increase predictability of our development process.		# '''Design & Design Review''': When a feature is in design and design review stage, details of the design and implementation will be worked out. At this stage, we can update the feature with a better estimation. This will help us schedule our work and increase predictability of our development process.

Song: /* Milestone Planning */

2012-08-03T18:41:24Z

Milestone Planning

← Older revision		Revision as of 18:41, 3 August 2012
Line 174:		Line 174:
	# Product managers and planners should reprioritize, add or remove milestone features if necessary.		# Product managers and planners should reprioritize, add or remove milestone features if necessary.
	# Program manager and team leads should organize and help each team with overall milestone planning and individual planning through team planning meetings and 1:1 conversations.		# Program manager and team leads should organize and help each team with overall milestone planning and individual planning through team planning meetings and 1:1 conversations.
	# Each team member is responsible for thinking through all features scheduled and make sure all P1 features will be completed and most of the P2/~~P3 features~~ will be completed ~~also~~.		# Each team member is responsible for thinking through all features scheduled and make sure all high features/bugs will be completed and most of the medium+ features/bugs will be completed as well.
	# Program manager should consolidate all changes into Bugzilla and update the corresponding wiki pages.		# Program manager should consolidate all changes into Bugzilla and update the corresponding wiki pages.

	Outcome:		Outcome:

	The outcome of the milestone planning should be an adjusted milestone plan to reflect the most current information, changes and decisions.		The outcome of the milestone planning should be an adjusted milestone plan to reflect the most current information, changes and decisions.

	==Milestone Review==		==Milestone Review==

Song: /* Milestone Weekly Activities */

2012-08-03T18:40:27Z

Milestone Weekly Activities

← Older revision		Revision as of 18:40, 3 August 2012
Line 137:		Line 137:
	** Product Manager: Reprioritize existing and new features if necessary, add or remove features in the milestone.		** Product Manager: Reprioritize existing and new features if necessary, add or remove features in the milestone.
	** Program Manager and the Team:		** Program Manager and the Team:
	*** Arrange resources to commit to the P1 features scheduled for this milestone		*** Arrange resources to commit to the high features/bugs scheduled for this milestone
	*** Reset the milestone goal for ~~P2, P3~~ features.		*** Reset the milestone goal for medium/medium+ features/bugs.
	** Each individual should consider other tasks they have in hands and make sure		** Each individual should consider other tasks they have in hands and make sure
	*** All P1 features can be delivered in the milestone.		*** All high features/bugs can be delivered in the milestone.
	*** Majority of ~~P2/P3~~ features can be delivered		*** Majority of medium+ features can be delivered
	*** Sets their own weekly goal and try to spread out pull requests for feature check-in among development weeks and avoid stampede of patch review and pull request in the last development week.		*** Sets their own weekly goal and try to spread out pull requests for feature check-in among development weeks and avoid stampede of patch review and pull request in the last development week.
	** Individuals: feature development and bug fixing		** Individuals: feature development and bug fixing
Line 156:		Line 156:
	** Program Manager: Release readiness meeting.		** Program Manager: Release readiness meeting.
	** Release Engineer: Release the milestone release.		** Release Engineer: Release the milestone release.



	==Milestone Planning==		==Milestone Planning==

Song: /* Release Criteria and Checklist */

2012-08-03T18:39:01Z

Release Criteria and Checklist

← Older revision		Revision as of 18:39, 3 August 2012
Line 100:		Line 100:
	Release criteria must be met and should be reviewed by stakeholders and the community in the release readiness meeting before release. Some generic criteria include the following:		Release criteria must be met and should be reviewed by stakeholders and the community in the release readiness meeting before release. Some generic criteria include the following:

	# All P1 features and tasks have to be completed.		# All high features/bugs and tasks have to be completed.
	# Majority of the ~~P2 and P3~~ features need to be completed.		# Majority of the medium+ features/bugs need to be completed.
	# The release need to meet certain quality standards, for example		# The release need to meet certain quality standards, for example
	## Passing full QA test, no high bugs open against the release		## Passing full QA test, no high bugs open against the release
Line 117:		Line 117:
	* Release package has been generated and posted on the public website (<nowiki>yoctoproject.org</nowiki>), and pushed to the mirror.		* Release package has been generated and posted on the public website (<nowiki>yoctoproject.org</nowiki>), and pushed to the mirror.
	* Release announcement email has been sent to the public mailing list		* Release announcement email has been sent to the public mailing list
	* A public blog entry has been published on <nowiki>yoctoproject.org</nowiki>		* A public blog entry has been published on <nowiki>yoctoproject.org</nowiki>

	=Milestone Releases=		=Milestone Releases=