Create Release Wiki

Release pages are used as a program management tool to make sure that the proper components with the appropriate versions are delivered to a customer.

There are two types of releases:

1. A "sales" release contains all architectures, all reference BSPs and some of our "optional" components (e.g., 653 & CFFS). It is intended for use in pre-sales activities and evaluations.
2. A named release is given to a customer when they have specified exactly what they want (i.e., which architectures, which BSPs, which optional components).

DDS vs Docker version numbers:
The dash number indicates how many times someone changed something on the FTP server that caused the distribution to be updated. If the only changes to a specific component version are to the component .zip files, then the dash numbers would be the same between Linux and Cygwin.

However, there are several files that are distinct between the systems: e.g., postinstall and pre-remove scripts, and also changes to the package2cygwin.py file that only affect one distribution (e.g., changing the set of dependent packages for Cygwin but not for Linux or vise versa). In those situations the build engine detects there are no differences and doesn't rebuild, so from then on the dash numbers are likely going to be different. Once a new version of the component is released, e.g., deosbook going from .15 to .20, the dash numbers will once again be in sync.

Pre-wiki creation:

1. Engineering identifies the need for a new release to a customer, as the result of new sale, a milestone release, or delta update release.
2. Engineering notifies the PLPLM team (eg, via email or at the PLPLM weekly meeting) to create the identified release(s); this information is captured in the PLPLM weekly meeting notes, located in the Engineering Handbook, section Meeting/Telecon Notes. It is also Engineering's responsibility to identify the contents of the DDS (correct components and revisions), see DDS_Build_for_Deos for details, and to communicate to the OA team the bsp, target hardware, and test suite. A charge number is also provided. The table below is an example of what is provided in the email and also captured on the release wiki page, DDS Test Summary section.
3. Process-wise, the next step is for the OpenArbor (OA) team to create the release, and perform OA regression testing. Once this is complete, the OA team notifies Engineering that the release testing is complete. At this point, the wiki page must be created prior to Engineering sending the request to QA for final approval (see DDS_Build_for_Deos#Request_QA_Approval).

Charge Code	BSP	Target Hardware	Test Suite	Remarks
Customer & Sales DDS build, test, QA approval	imx8qm	DeosIMX8QM	Platform Integration

Steps needed to create a Release WIKI page:
Start with a clone of a recent Release page; ideally, use the customer's previous Release page as a template (if one exists).

• Update the one line description of the release.
• Update the previous distribution with the candidate distribution (always referenced from the \\nx3000\ship\dds\windows\approved\ directory). Update the candidate distribution with the DDS tested by OA team; the distribution will be located on one of the machines used by the OA team to build the DDS releases: scorebuild (32-bit builds, eg greys baseline), or ddsbuild.ddci.com (64-bit builds, eg, indie baseline). Note: the baseline is identified on the customer program page.
• Update the ftp link archive number: this is located in the cover letter (found in root directory) of the actual DDS, appended to the baseline, eg, greys-15550865779.
• Identify the build method, either new or patch.
• Update "Components to Work" section: this involves doing a diff of the setup.ini file between the previous and current distributions. Planned features/updates are identified in PM.com, but unplanned updates based on PCRs are not identified in PM.com. The "diff" is used to identify unreleased versions being worked, which will help identify unplanned updates. Note: to ensure updated components don't slip through the cracks, the diff should be performed when the release wiki is created, and again before sending the DDS to OA for testing.
• For a diff between original customer Sales deliver and customer Named deliver, do the following before performing the diff between a new customer deliver and a prior customer delivery steps:

 Copy the Sales deliver to a local folder and replace Sales with the Customer name.
 Edit the setup file to make the Sale customer definition match the Customer definition.
 Execute the diff script below, making sure to point to the local copy of the modified file.

• For a diff between a new customer deliver and a prior customer delivery, do the following:

 Execute the script to create the diff, located at /scm/maintainer-tools/cygwin/cmp-ini-root.py.  Modify the build machine, 
 DDS names and customer name in the following example:
 ./cmp-ini-root.py //nx3000.ddci.com/ship/dds/windows/approved/DDS-durants-deos-jupiter-20190222/deos-heartos-posix/x86_64/setup.ini //ddsbuild.ddci.com/DDCI_integration/DDS-durants-deos-jupiter-20190415/deos-heartos-posix/x86_64/setup.ini customer-durants &> DDS-durants-deos-jupiter-20190415.mediawiki.txt

• For a diff between a "patch"ed customer deliver and a prior customer delivery, do the following to ensure only the expected components have been changed:

Example:

BASELINE=jupiter
CUSTOMER=harrys
NEW_DATE=20180419
OLD_DATE=20180205
diff -rq //nx3000.ddci.com/ship/dds/windows/approved/DDS-${CUSTOMER}-deos-${BASELINE}-${OLD_DATE} //ddsbuild.ddci.com/DDCI_integration/DDS-${CUSTOMER}-deos-${BASELINE}-${NEW_DATE} | sort > DDS-${CUSTOMER}-deos-${BASELINE}-${NEW_DATE}.txt

• Copy the generated table text into the wiki page. But first, remove the dummy packages and packages marked as "dev" and fix any exception.
• Update the other sections from the generated text: Updated Packages info goes under "Added/Modified Packages", and Removed Packages info goes under "Removed Packages".

 * Note: When updating from 32 bit to 64 bit, add this comment before listing "Added/Modified Packages"
   Cygwin was modified to the 20180401 set of packages for 64 bit Cygwin. In addition the following DDC-I generated packages were added/modified: 
   See [| Deos Durants2 OA Release] for an example

• Update Test Summary section to point to the OpenArbor test report (provided by the OpenArbor team).

*For a patch build, all or partial testing may be done by the customer. That should be noted.

• Update the categories at the end of the page to reflect that the release is "active".
• Update the categories at the end of the page to reflect that the release is "completed" once the emails to the customer have been sent.
• Update the Customer page milestone table for the delivery sent.

• For Sales releases, once QA approves, make sure the release is moved to \\nx3000\ship and let sales know it has been updated for their use.

• To find ftp server unrelease links
  • ssh deosftp
    
  • cd pub/
    
  • find *-products -type l -iname '*unrelease*' -mtime -30 | xargs ls -ld

---