Yocto Project v. 1.0 Release Cycle - Revision history

Eflanagan: /* Date Slip */

2011-01-11T00:12:39Z

Date Slip

← Older revision		Revision as of 00:12, 11 January 2011
Line 94:		Line 94:
	As this is a theoretical scenario, we should be prepared to do some small amount of playing it by ear when it comes to slipped dates. The obvious places where we're going to identify a slipped date is at the release readiness reviews, which is why there are more of them during this release process than the last.		As this is a theoretical scenario, we should be prepared to do some small amount of playing it by ear when it comes to slipped dates. The obvious places where we're going to identify a slipped date is at the release readiness reviews, which is why there are more of them during this release process than the last.

	[[Image:~~Slipped~~.jpg\|thumb\|''Slipped Date Release Windows 1'']]		[[Image:Slipped1.jpg\|thumb\|''Slipped Date Release Windows 1'']]

	[[Image:~~Slipped~~.jpg\|thumb\|''Slipped Date Release Windows 2'']]		[[Image:Slipped2.jpg\|thumb\|''Slipped Date Release Windows 2'']]

Eflanagan: /* Mirrors */

2011-01-11T00:12:03Z

Mirrors

← Older revision		Revision as of 00:12, 11 January 2011
Line 83:		Line 83:
	One week into the release cycle, the Gold build of Yocto v1.0 should be rsynced to the mirrors non-world accessable. This will allow time for mirror propagation. Once documentation is considered complete, this should be added to the rsync directory (NOT the tarball). Once the final Release Readiness Review is complete and the release is given the green light, the world readable bit should be set on the rsync directory and files, the announcement sent out and the release should be considered complete.		One week into the release cycle, the Gold build of Yocto v1.0 should be rsynced to the mirrors non-world accessable. This will allow time for mirror propagation. Once documentation is considered complete, this should be added to the rsync directory (NOT the tarball). Once the final Release Readiness Review is complete and the release is given the green light, the world readable bit should be set on the rsync directory and files, the announcement sent out and the release should be considered complete.

	[[Image:Release.jpg\|thumb~~\| left~~ \| ''Release Window'']]		[[Image:Release.jpg\|thumb\| ''Release Window'']]

	=== Date Slip ===		=== Date Slip ===

Eflanagan: /* Release Branch Generation */

2011-01-11T00:11:53Z

Release Branch Generation

← Older revision		Revision as of 00:11, 11 January 2011
Line 36:		Line 36:
	At the end of the Master Stabilization Cycle, master is tagged and branched as the 1.0 RC (naming conventions. If we don't have them yet, I'll be making them up soon) and all developers, QA and build and release, who need to fix bugs for the upcoming release should switch to the release candidate branch of master. Once the release branch is generated, all pulls that have been staged to distro/testing should occur and master is now considered unfrozen.		At the end of the Master Stabilization Cycle, master is tagged and branched as the 1.0 RC (naming conventions. If we don't have them yet, I'll be making them up soon) and all developers, QA and build and release, who need to fix bugs for the upcoming release should switch to the release candidate branch of master. Once the release branch is generated, all pulls that have been staged to distro/testing should occur and master is now considered unfrozen.

	[[File:Master.jpg \|thumb ~~\|left~~\|''Master Release Cycle Overview'']]		[[File:Master.jpg \|thumb \|''Master Release Cycle Overview'']]

	=== Release Candidate Verification/Validation Cycle ===		=== Release Candidate Verification/Validation Cycle ===

Eflanagan: /* Final Release Generation */

2011-01-11T00:11:27Z

Final Release Generation

← Older revision		Revision as of 00:11, 11 January 2011
Line 61:		Line 61:
	At the end of the Release Candidate Cycle, the release candidate branch is tagged as (whatever the naming convention is for a major/minor release).		At the end of the Release Candidate Cycle, the release candidate branch is tagged as (whatever the naming convention is for a major/minor release).

	[[File:RCP.jpg \| thumb \| ~~left\|~~ ''Release Candidate Cycle Overview'']]		[[File:RCP.jpg \| thumb \| ''Release Candidate Cycle Overview'']]

	=== Release Window ===		=== Release Window ===

Eflanagan: /* Release Branch Generation */

2011-01-11T00:11:13Z

Release Branch Generation

← Older revision		Revision as of 00:11, 11 January 2011
Line 36:		Line 36:
	At the end of the Master Stabilization Cycle, master is tagged and branched as the 1.0 RC (naming conventions. If we don't have them yet, I'll be making them up soon) and all developers, QA and build and release, who need to fix bugs for the upcoming release should switch to the release candidate branch of master. Once the release branch is generated, all pulls that have been staged to distro/testing should occur and master is now considered unfrozen.		At the end of the Master Stabilization Cycle, master is tagged and branched as the 1.0 RC (naming conventions. If we don't have them yet, I'll be making them up soon) and all developers, QA and build and release, who need to fix bugs for the upcoming release should switch to the release candidate branch of master. Once the release branch is generated, all pulls that have been staged to distro/testing should occur and master is now considered unfrozen.

	[[File:Master.jpg \|thumb \|left ~~\| 700px~~ \|''Master Release Cycle Overview'']]		[[File:Master.jpg \|thumb \|left\|''Master Release Cycle Overview'']]

	=== Release Candidate Verification/Validation Cycle ===		=== Release Candidate Verification/Validation Cycle ===

Eflanagan: /* Final Release Generation */

2011-01-11T00:10:56Z

Final Release Generation

← Older revision		Revision as of 00:10, 11 January 2011
Line 61:		Line 61:
	At the end of the Release Candidate Cycle, the release candidate branch is tagged as (whatever the naming convention is for a major/minor release).		At the end of the Release Candidate Cycle, the release candidate branch is tagged as (whatever the naming convention is for a major/minor release).

	[[File:RCP.jpg \| thumb ~~\| 700px~~ \| left\| ''Release Candidate Cycle Overview'']]		[[File:RCP.jpg \| thumb \| left\| ''Release Candidate Cycle Overview'']]

	=== Release Window ===		=== Release Window ===

Eflanagan: /* Mirrors */

2011-01-11T00:10:45Z

Mirrors

← Older revision		Revision as of 00:10, 11 January 2011
Line 83:		Line 83:
	One week into the release cycle, the Gold build of Yocto v1.0 should be rsynced to the mirrors non-world accessable. This will allow time for mirror propagation. Once documentation is considered complete, this should be added to the rsync directory (NOT the tarball). Once the final Release Readiness Review is complete and the release is given the green light, the world readable bit should be set on the rsync directory and files, the announcement sent out and the release should be considered complete.		One week into the release cycle, the Gold build of Yocto v1.0 should be rsynced to the mirrors non-world accessable. This will allow time for mirror propagation. Once documentation is considered complete, this should be added to the rsync directory (NOT the tarball). Once the final Release Readiness Review is complete and the release is given the green light, the world readable bit should be set on the rsync directory and files, the announcement sent out and the release should be considered complete.

	[[Image:Release.jpg\|thumb~~\| 700px~~ \| left \| ''Release Window'']]		[[Image:Release.jpg\|thumb\| left \| ''Release Window'']]

	=== Date Slip ===		=== Date Slip ===

Eflanagan: /* Date Slip */

2011-01-11T00:10:27Z

Date Slip

← Older revision		Revision as of 00:10, 11 January 2011
Line 94:		Line 94:
	As this is a theoretical scenario, we should be prepared to do some small amount of playing it by ear when it comes to slipped dates. The obvious places where we're going to identify a slipped date is at the release readiness reviews, which is why there are more of them during this release process than the last.		As this is a theoretical scenario, we should be prepared to do some small amount of playing it by ear when it comes to slipped dates. The obvious places where we're going to identify a slipped date is at the release readiness reviews, which is why there are more of them during this release process than the last.

	[[Image:Slipped.jpg\|thumb\|''Slipped Date Release Windows 1 ~~and~~ 2'']]		[[Image:Slipped.jpg\|thumb\|''Slipped Date Release Windows 1'']]

			[[Image:Slipped.jpg\|thumb\|''Slipped Date Release Windows 2'']]

Eflanagan: /* Mirrors */

2011-01-11T00:09:54Z

Mirrors

← Older revision		Revision as of 00:09, 11 January 2011
Line 83:		Line 83:
	One week into the release cycle, the Gold build of Yocto v1.0 should be rsynced to the mirrors non-world accessable. This will allow time for mirror propagation. Once documentation is considered complete, this should be added to the rsync directory (NOT the tarball). Once the final Release Readiness Review is complete and the release is given the green light, the world readable bit should be set on the rsync directory and files, the announcement sent out and the release should be considered complete.		One week into the release cycle, the Gold build of Yocto v1.0 should be rsynced to the mirrors non-world accessable. This will allow time for mirror propagation. Once documentation is considered complete, this should be added to the rsync directory (NOT the tarball). Once the final Release Readiness Review is complete and the release is given the green light, the world readable bit should be set on the rsync directory and files, the announcement sent out and the release should be considered complete.

	[[Image:Release.jpg\|thumb\| ''Release Window'']]		[[Image:Release.jpg\|thumb\| 700px \| left \| ''Release Window'']]

	=== Date Slip ===		=== Date Slip ===

Eflanagan: /* Release Branch Generation */

2011-01-11T00:03:17Z

Release Branch Generation

← Older revision		Revision as of 00:03, 11 January 2011
Line 36:		Line 36:
	At the end of the Master Stabilization Cycle, master is tagged and branched as the 1.0 RC (naming conventions. If we don't have them yet, I'll be making them up soon) and all developers, QA and build and release, who need to fix bugs for the upcoming release should switch to the release candidate branch of master. Once the release branch is generated, all pulls that have been staged to distro/testing should occur and master is now considered unfrozen.		At the end of the Master Stabilization Cycle, master is tagged and branched as the 1.0 RC (naming conventions. If we don't have them yet, I'll be making them up soon) and all developers, QA and build and release, who need to fix bugs for the upcoming release should switch to the release candidate branch of master. Once the release branch is generated, all pulls that have been staged to distro/testing should occur and master is now considered unfrozen.

	[[File:Master.jpg \|thumb \|left \| ~~500px~~ \|''Master Release Cycle Overview'']]		[[File:Master.jpg \|thumb \|left \| 700px \|''Master Release Cycle Overview'']]

	=== Release Candidate Verification/Validation Cycle ===		=== Release Candidate Verification/Validation Cycle ===