Hi Fernando, I guess "Long Team release" should be "Long Term release". :) Best Regards Shuicheng From: Hernandez Gonzalez, Fernando [mailto:fernando.hernandez.gonzalez@intel.com] Sent: Tuesday, July 17, 2018 6:54 AM To: 'starlingx-discuss@lists.starlingx.io' <starlingx-discuss@lists.starlingx.io> Cc: Troyer, Dean <dean.troyer@intel.com> Subject: [Starlingx-discuss] Design and Documentation for our Starlingx/Release Plan Web Page. Hi Team, Last Friday 13th we discussed our first draft about how are we going to release our builds in our Starlingx/Release Plan<https://wiki.openstack.org/wiki/StarlingX/Release_Plan> official page. Please take a look into this first proposal, our first approach is releasing something clean and neat, comments and suggestions are well welcome, more things can be added/removed if necessary. AR All, I have an Action Request for every Stx pioneer who would like to be in the Release Team (basically would be Point of Contact regarding Release plan matters, currently we have <Mario Alfredo Carrillo Arevalo> Thanks Mario for help me out with this first draft) Please look at the text below for web page explanation. For those who are more visual people see attached image. StarlingX/Release Plan List of releases Describing Current Table Version Link should be something like https://git.stx.com/stx.2018.08.0x.tar.gz: containing: · .tar, .img, .iso, or wathever is decided. · Rpms, srpm. · Debug keys - if apply. · Packages. Remark: at the end something similar like Clearlinux.org deploys Clearlinux Link<https://cdn.download.clearlinux.org/releases/23700/clear/> Docs or Release Notes Link should re direct you to the Release notes Web Page containing at least: · Version link. · Freeze code Date. · Major features list. · List of Code Changes - higher level. · Validation done against the build. e.g. "This build has been validated with Sanity test <git repo link>" Remark: where git repo link redirect to test cases folder stored in git. · Known issues. Same comments apply for Future Table. Management of releases Release cadence and Schedule Releases are published in a time based fashion: · Every Long Term period with quarterly updates. · Every Quarterly with monthly updates. Monthly release · Each month in the 2nd week of the month a branch will be pulled. · Branch name format stx.YY.MM.patch# e.g. stx.2018.08.0x (where "0x" is a patch number) Quarterly release · 2nd month in the quarter. · For each quarterly release, the code freeze for that release is the 2nd week in the 2nd month in the quarter. Long Team release · TBD Support length · Quarterly releases are supported for 6 months. · Long Term releases are out of plan so far. Release team · Visit the release team page Release Plan Page Out of Scope list. **Remark: our current plan marked below items out of scope and based on the project needs it could be added. We want to start with something simple. · Web Page containing Stx Details of Release Schedule. o Detail Schedule with feature freeze, figure it out bug handling, known issues for the release, point to backlog in the future, what will be fixed, etc. [cid:image003.png@01D41DB5.9BE96F80] · Branch support length should be in Dev doc. · IRC, [Starlingx-discuss] channel is in the Starlingx main page. · Release/build announcements will be in the Starlingx main page. · Starlingx Technical Committee should be in Starlingx main page or Dev doc. Thanks. Fernando Hernandez Gonzalez Software Engineer Avenida del Bosque #1001 Col, El Bajío Zapopan, Jalisco MX, 45019 ____________________________________ Office: +52.33.16.45.01.34 inet 86450134

[Formatting in these messages is likely to be mangled for many readers and completely stripped in the archives. Attachments are also stripped in the archives. Here is how the original message looks: http://lists.starlingx.io/pipermail/starlingx-discuss/2018-July/000232.html] On Mon, Jul 16, 2018 at 5:54 PM, Hernandez Gonzalez, Fernando < fernando.hernandez.gonzalez@intel.com> wrote:

Please take a look into this first proposal, our first approach is releasing something clean and neat, comments and suggestions are well welcome, more things can be added/removed if necessary.

I think we need to include a definition of exactly what a StarlingX Release/milestone is: * A StarlingX milestone/release is a branch in the source code repositories that: * is considered stable * will have no additional features added * will backport bug fixes for critical issues only * will be maintained in the canonical repositories for a specified minimum period * The list of repos included is maintained in stx-manifest/default.xml (or similar) for any given release. (Note: this file included non-StarlingX-managed repos, only repos from the "starlingx" and "stx-staging" remotes are included.) Based on that definition the release process for a milestone might look like: * check out the current repos * create branches at either HEAD or a specific SHA * push branches back to master repos * create new review to update the .gitreview file in each repo (this _should_ be the first merge on the new branch, there may be additional branch-specific updates required here at some point (release notes are common)) * update default.xml in the stx-manifest stable branch to pull the milestone branches rather than master The process for the periodic releases would include the milestone process and additionally: * when the RC period is concluded tag HEAD on the stable branches to denote the actual release We should consider if we want to branch stx-tools or not as its intended to be release-agnostic and should not have any release-specific contents. We may want to branch it anyway. Thoughts? dt -- Dean Troyer dtroyer@gmail.com