Meta-intel Release Process - Revision history

Anuj Mittal at 09:27, 20 July 2018

2018-07-20T09:27:09Z

← Older revision		Revision as of 09:27, 20 July 2018
Line 2:		Line 2:

	This pages attempts to capture the meta-intel release process as it exists - it isn't meant to be an official or binding document.		This pages attempts to capture the meta-intel release process as it exists - it isn't meant to be an official or binding document.

	Also, this process only addresses the BSPs built and released by the Yocto Autobuilder team, and tested by the Yocto QA team - it doesn't address the release process for any BSPs that are managed outside of that process, such as the ISG BSPs, which may be built using a separate autobuilder and tested by ISG, i.e. which have their own release process, though their metadata may exist within the meta-intel and linux-yocto repositories.

	=== Overall Responsibilities ===		=== Overall Responsibilities ===
Line 33:		Line 31:
	The autobuilder maintainers are the only ones who can create new branches and release tags in meta-intel, and will do so when necessary as required to generate the infrastructure needed for a release.		The autobuilder maintainers are the only ones who can create new branches and release tags in meta-intel, and will do so when necessary as required to generate the infrastructure needed for a release.
	* Once a new branch is created for the release, the meta-intel maintainer(s) will add new commits to both master and the release branch up until the time of release (as appropriate - some patches may only be intended for master or the release)		* Once a new branch is created for the release, the meta-intel maintainer(s) will add new commits to both master and the release branch up until the time of release (as appropriate - some patches may only be intended for master or the release)


	=== Release Notes ===		=== Release Notes ===

Anuj Mittal: /* meta-intel BSP release version scheme */

2018-07-20T09:25:53Z

meta-intel BSP release version scheme

← Older revision		Revision as of 09:25, 20 July 2018
Line 34:		Line 34:
	* Once a new branch is created for the release, the meta-intel maintainer(s) will add new commits to both master and the release branch up until the time of release (as appropriate - some patches may only be intended for master or the release)		* Once a new branch is created for the release, the meta-intel maintainer(s) will add new commits to both master and the release branch up until the time of release (as appropriate - some patches may only be intended for master or the release)


	~~=== meta-intel BSP release version scheme ===~~

	Starting with the poky v1.6.1 release in July 2014, meta-intel BSPs started following a new version scheme. With the new scheme meta-intel BSP tarballs get the meta-intel layer version string, along with the compatible poky layer release name and version needed for the BSP. For example in July 2014 the crownbay-noemgd BSP was released as crownbay-noemgd-1.0-daisy-1.6.1 as seen here [https://www.yoctoproject.org/downloads/bsps/daisy161/crown-bay-0 YP BSP link]

	~~The new format for releasing meta-intel BSPs is~~

	~~<BSP Name>-<meta intel layer version in the major.minor format>-<the poky release name and version compatible for this BSP>~~
	~~For Example: crownbay-noemgd-1.0-daisy-1.6.1~~

	~~Note that meta-intel BSPs will generally be compatible with subsequent dot release of the poky layer, because the dot release are for bug fixes, and they do not add new features.~~

	~~==== Incrementing meta-intel BSP version ====~~

	The major part of the meta-intel layer BSP version is incremented for every major release of Yocto Project release. For the new BSP releases made for the poky dot releases, or new BSP releases which do not change the requirement of the compatible poky release, the minor part of the meta-intel layer version is incremented to denote it as a dot release.

	=== Release Notes ===		=== Release Notes ===

Anuj Mittal at 09:22, 20 July 2018

2018-07-20T09:22:41Z

@@ Line 34: / Line 34: @@
 * Once a new branch is created for the release, the meta-intel maintainer(s) will add new commits to both master and the release branch up until the time of release (as appropriate - some patches may only be intended for master or the release)
 === meta-intel BSP release version scheme ===
@@ Line 69: / Line 62: @@
 According to the Yocto Project compliance requirements, no meta-intel BSP can be released without testing data.  The webpage for each BSP must contain a link to the testing data generated for every image contained in a released BSP.  For the BSPs tested by Yocto QA, the QA test report should be the one linked to for those BSPs.

Nitinkamble: /* meta-intel BSP release version scheme */

2014-10-08T16:02:19Z

meta-intel BSP release version scheme

← Older revision		Revision as of 16:02, 8 October 2014
Line 44:		Line 44:
	=== meta-intel BSP release version scheme ===		=== meta-intel BSP release version scheme ===

	Starting with the poky v1.6.1 release in July 2014, meta-intel BSPs started following a new version scheme. With the new scheme meta-intel ~~BSPs~~ get the meta-intel layer version string, along with the compatible poky release name and version needed for the BSP. For example in July 2014 the crownbay-noemgd BSP was ~~relelased~~ as crownbay-noemgd-1.0-daisy-1.6.1 as seen here [https://www.yoctoproject.org/downloads/bsps/daisy161/crown-bay-0 YP BSP link]		Starting with the poky v1.6.1 release in July 2014, meta-intel BSPs started following a new version scheme. With the new scheme meta-intel BSP tarballs get the meta-intel layer version string, along with the compatible poky layer release name and version needed for the BSP. For example in July 2014 the crownbay-noemgd BSP was released as crownbay-noemgd-1.0-daisy-1.6.1 as seen here [https://www.yoctoproject.org/downloads/bsps/daisy161/crown-bay-0 YP BSP link]

	The new format for releasing meta-intel BSPs is		The new format for releasing meta-intel BSPs is
Line 55:		Line 55:
	==== Incrementing meta-intel BSP version ====		==== Incrementing meta-intel BSP version ====

	The major part of the meta-intel layer BSP version is incremented for every major release of Yocto Project release. For the new BSP releases made for the poky dot releases, or new BSP releases which do not change the requirement of the ~~oldest~~ poky release, the minor part of the meta-intel layer version is incremented to denote it as a dot release.		The major part of the meta-intel layer BSP version is incremented for every major release of Yocto Project release. For the new BSP releases made for the poky dot releases, or new BSP releases which do not change the requirement of the compatible poky release, the minor part of the meta-intel layer version is incremented to denote it as a dot release.

	=== Release Notes ===		=== Release Notes ===

Nitinkamble: /* meta-intel BSP directory naming convention */

2014-10-08T15:58:47Z

meta-intel BSP directory naming convention

← Older revision		Revision as of 15:58, 8 October 2014
Line 41:		Line 41:

	Note: CPU name and CRB name are optional if the BSP supports more than 1 CPU or CRB		Note: CPU name and CRB name are optional if the BSP supports more than 1 CPU or CRB

			=== meta-intel BSP release version scheme ===

			Starting with the poky v1.6.1 release in July 2014, meta-intel BSPs started following a new version scheme. With the new scheme meta-intel BSPs get the meta-intel layer version string, along with the compatible poky release name and version needed for the BSP. For example in July 2014 the crownbay-noemgd BSP was relelased as crownbay-noemgd-1.0-daisy-1.6.1 as seen here [https://www.yoctoproject.org/downloads/bsps/daisy161/crown-bay-0 YP BSP link]

			The new format for releasing meta-intel BSPs is

			<BSP Name>-<meta intel layer version in the major.minor format>-<the poky release name and version compatible for this BSP>
			For Example: crownbay-noemgd-1.0-daisy-1.6.1

			Note that meta-intel BSPs will generally be compatible with subsequent dot release of the poky layer, because the dot release are for bug fixes, and they do not add new features.

			==== Incrementing meta-intel BSP version ====

			The major part of the meta-intel layer BSP version is incremented for every major release of Yocto Project release. For the new BSP releases made for the poky dot releases, or new BSP releases which do not change the requirement of the oldest poky release, the minor part of the meta-intel layer version is incremented to denote it as a dot release.

	=== Release Notes ===		=== Release Notes ===

Song: /* Branch and Tag Management */

2013-10-01T21:13:01Z

Branch and Tag Management

← Older revision		Revision as of 21:13, 1 October 2013
Line 33:		Line 33:
	The autobuilder maintainers are the only ones who can create new branches and release tags in meta-intel, and will do so when necessary as required to generate the infrastructure needed for a release.		The autobuilder maintainers are the only ones who can create new branches and release tags in meta-intel, and will do so when necessary as required to generate the infrastructure needed for a release.
	* Once a new branch is created for the release, the meta-intel maintainer(s) will add new commits to both master and the release branch up until the time of release (as appropriate - some patches may only be intended for master or the release)		* Once a new branch is created for the release, the meta-intel maintainer(s) will add new commits to both master and the release branch up until the time of release (as appropriate - some patches may only be intended for master or the release)

			=== meta-intel BSP directory naming convention ===

			All directories for meta-intel BSPs should be named in the format of:

			meta-platform[-cpu][-crb]

			Note: CPU name and CRB name are optional if the BSP supports more than 1 CPU or CRB

	=== Release Notes ===		=== Release Notes ===

Song: /* Overall Responsibilities */

2013-05-31T17:00:55Z

Overall Responsibilities

← Older revision		Revision as of 17:00, 31 May 2013
Line 19:		Line 19:
	* The yocto website maintainers make the tarballs available from pages containing the release notes for each BSP, along with test reports and image verification status for each (see sections below for details).		* The yocto website maintainers make the tarballs available from pages containing the release notes for each BSP, along with test reports and image verification status for each (see sections below for details).
	* Any problems not fixed by the BSP maintainers need to be noted by the maintainer and sent to the website maintainer and Yocto documentation maintainer as 'Layer-specific Notes' to be appended to each affected BSP's release notes (see below).		* Any problems not fixed by the BSP maintainers need to be noted by the maintainer and sent to the website maintainer and Yocto documentation maintainer as 'Layer-specific Notes' to be appended to each affected BSP's release notes (see below).

			=== Basic Process ===
			Even though exceptions may occur for some BSPs, this is the basic process we use to release all meta-intel BSPs:

			* All meta-intel BSPs will be build along with each Yocto Project milestone release candidates. Then QA will follow and results will be integrated with the full pass QA report.
			* Bugs will be fixed/handled by maintainers or others.
			* Within the first week after Yocto Project major release, RC1 for meta-intel BSPs will be built and tested.
			* Within the second week after Yocto Project major release, RC2 for meta-intel BSPs will be built and tested.
			* meta-intel BSPs will be released by the end of the third week after Yocto Project major release.

	=== Branch and Tag Management ===		=== Branch and Tag Management ===

Tzanussi at 18:53, 23 April 2013

2013-04-23T18:53:34Z

← Older revision		Revision as of 18:53, 23 April 2013
Line 8:		Line 8:

	The meta-intel repository consists of a set of BSPs and some common metadata. Because those BSPs each have separate owners, we can't make a blanket assertion that all those BSPs will be released as part of a meta-intel release. It would be nice to be able to do so, but in reality, different groups of maintainers may decide to do separate releases. As such. this section only describes the perceived responsibilities of the maintainers for the set of BSPs controlled by the Yocto team.		The meta-intel repository consists of a set of BSPs and some common metadata. Because those BSPs each have separate owners, we can't make a blanket assertion that all those BSPs will be released as part of a meta-intel release. It would be nice to be able to do so, but in reality, different groups of maintainers may decide to do separate releases. As such. this section only describes the perceived responsibilities of the maintainers for the set of BSPs controlled by the Yocto team.

			The Yocto Project Program Manager has the ultimate responsibility for coordinating the various BSP owners and managing the overall meta-intel release.

	* Basically the BSP maintainer(s) are responsible for tracking the release milestones and making sure the BSPs are up-to-date and releasable with respect to the poky release. This includes all recipe upgrades and bugfixes intended to go into the release.		* Basically the BSP maintainer(s) are responsible for tracking the release milestones and making sure the BSPs are up-to-date and releasable with respect to the poky release. This includes all recipe upgrades and bugfixes intended to go into the release.

Tzanussi at 18:50, 23 April 2013

2013-04-23T18:50:34Z

← Older revision		Revision as of 18:50, 23 April 2013
Line 4:		Line 4:

	Also, this process only addresses the BSPs built and released by the Yocto Autobuilder team, and tested by the Yocto QA team - it doesn't address the release process for any BSPs that are managed outside of that process, such as the ISG BSPs, which may be built using a separate autobuilder and tested by ISG, i.e. which have their own release process, though their metadata may exist within the meta-intel and linux-yocto repositories.		Also, this process only addresses the BSPs built and released by the Yocto Autobuilder team, and tested by the Yocto QA team - it doesn't address the release process for any BSPs that are managed outside of that process, such as the ISG BSPs, which may be built using a separate autobuilder and tested by ISG, i.e. which have their own release process, though their metadata may exist within the meta-intel and linux-yocto repositories.

			=== Overall Responsibilities ===

			The meta-intel repository consists of a set of BSPs and some common metadata. Because those BSPs each have separate owners, we can't make a blanket assertion that all those BSPs will be released as part of a meta-intel release. It would be nice to be able to do so, but in reality, different groups of maintainers may decide to do separate releases. As such. this section only describes the perceived responsibilities of the maintainers for the set of BSPs controlled by the Yocto team.

			* Basically the BSP maintainer(s) are responsible for tracking the release milestones and making sure the BSPs are up-to-date and releasable with respect to the poky release. This includes all recipe upgrades and bugfixes intended to go into the release.
			* At each release candidate, the autobuilder team generates the images passes them on to QA for testing.
			* QA tests and provides feedback on how the BSPs meet the release criteria.
			* The BSP maintainer(s) fix any problems found by QA, and the cycle repeats itself in the next RC cycle, until all BSPs can be released.

			Once the BSPs are ready to be released from the BSP maintainer's and QA team standpoint, the autobuilder team generates release tarballs for each BSP and makes them available to the Yocto website maintainers for availability as downloads on the Yocto website.
			* The yocto website maintainers make the tarballs available from pages containing the release notes for each BSP, along with test reports and image verification status for each (see sections below for details).
			* Any problems not fixed by the BSP maintainers need to be noted by the maintainer and sent to the website maintainer and Yocto documentation maintainer as 'Layer-specific Notes' to be appended to each affected BSP's release notes (see below).

	=== Branch and Tag Management ===		=== Branch and Tag Management ===

Tzanussi at 17:22, 23 April 2013

2013-04-23T17:22:08Z

← Older revision		Revision as of 17:22, 23 April 2013
Line 4:		Line 4:

	Also, this process only addresses the BSPs built and released by the Yocto Autobuilder team, and tested by the Yocto QA team - it doesn't address the release process for any BSPs that are managed outside of that process, such as the ISG BSPs, which may be built using a separate autobuilder and tested by ISG, i.e. which have their own release process, though their metadata may exist within the meta-intel and linux-yocto repositories.		Also, this process only addresses the BSPs built and released by the Yocto Autobuilder team, and tested by the Yocto QA team - it doesn't address the release process for any BSPs that are managed outside of that process, such as the ISG BSPs, which may be built using a separate autobuilder and tested by ISG, i.e. which have their own release process, though their metadata may exist within the meta-intel and linux-yocto repositories.

			=== Branch and Tag Management ===

			The autobuilder maintainers are the only ones who can create new branches and release tags in meta-intel, and will do so when necessary as required to generate the infrastructure needed for a release.
			* Once a new branch is created for the release, the meta-intel maintainer(s) will add new commits to both master and the release branch up until the time of release (as appropriate - some patches may only be intended for master or the release)

	=== Release Notes ===		=== Release Notes ===