You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In general response codes in the 400 and 500 range are errors so keeping persistent http connections open would pose issues with the requirements of persistent connections. However some 400 codes, like 404, can be safely sent without closing the connection. This feature is to investigate a design that allows us to keep using a connection with those errors. For traditional http a 404 is a rare occurrence, but when http is used for computer to computer interaction a 404 is more likely to be normal with the creation of a new connection being an overhead if many requests are being made.
Documents
When available, add links to required feature documents. Use "N/A" to mark particular documents which are not required by the feature.
Click "Share" > select "People with link" > click "Link Settings" > under "Link Expiration" select "Disable Shared Link on" > set an expiration date ~10 years into the future
Important: Labels are used to trigger particular steps and must be added as indicated.
Prioritization (Complete Before Development Starts)
The (OpenLiberty/chief-architect) and area leads are responsible for prioritizing the features and determining which features are being actively worked on.
Epics can be added to the board in one of two ways:
From this issue, use the "Projects" section to select the appropriate project board.
From the appropriate project board click "Add card" and select your Feature Epic issue
Priority assigned
Attend the Liberty Backlog Prioritization meeting
Design (Complete Before Development Starts)
Design preliminaries determine whether a formal design, which will be provided by an Upcoming Feature Overview (UFO) document, must be created and reviewed. A formal design is required if the feature requires any of the following: UI, Serviceability, SVT, Performance testing, or non-trivial documentation/ID.
Add the public link to the UFO in Box to the Documents section.
The UFO must always accurately reflect the final implementation of the feature. Any changes must be first approved. Afterwards, update the UFO by creating a copy of the original approved slide(s) at the end of the deck and prepend "OLD" to the title(s). A single updated copy of the slide(s) should take the original's place, and have its title(s) prepended with "UPDATED".
Note: For stabilized, superseded, and discontinued feature/capability, skip the Beta section of the template (you may delete it). Otherwise, proceed as normal.
A feature must be prioritized before any implementation work may begin to be delivered (inaccessible/no-ship). However, a design focused approach should still be applied to features, and developers should think about the feature design prior to writing and delivering any code.
Besides being prioritized, a feature must also be socialized (or No Design Approved) before any beta code may be delivered. All new Liberty content must be inaccessible in our GA releases until it is Feature Complete by either marking it kind=noship or beta fencing it.
Code may not GA until this feature has obtained the "Design Approved" or "No Design Approved" label, along with all other tasks outlined in the GA section.
Feature Development Begins
Add the In Progress label
Legal and Translation
In order to avoid last minute blockers and significant disruptions to the feature, the legal items need to be done as early in the feature process as possible, either in design or as early into the development as possible. Similarly, translation is to be done concurrently with development. Both MUST be completed before Beta or GA is requested.
Legal (Complete before Feature Complete Date)
Changed or new open source libraries are cleared and approved, or N/A. (Legal Release Services/Cass Tucker/Release PM).
Licenses and Certificates of Originality (COOs) are updated, or N/A
Translation (Complete 1 week before Feature Complete Date)
PII updates are merged, or N/A. Note timing with translation shipments.
Innovation (Complete 1 week before Feature Complete Date)
Consider whether any aspects of the feature may be patentable. If any identified, disclosures have been submitted.
Beta
In order to facilitate early feedback from users, all new features and functionality should first be released as part of a beta release.
Beta Code
Beta fence the functionality
kind=beta, ibm:beta, ProductInfo.getBetaEdition()
Beta development complete and feature ready for inclusion in a beta release
Add label target:beta and the appropriate target:YY00X-beta (where YY00X is the targeted beta version).
Feature delivered into beta
(OpenLiberty/release-manager) adds label release:YY00X-beta (where YY00X is the first beta version that included the functionality).
Add a link to the beta blog issue in the Documents section.
Note: This is for inclusion into the overall beta release blog post. If, in addition, you'd also like to create a dedicated blog post about your feature, then follow the "Standalone Feature Blog Post" instructions under the Other Deliverables section.
GA
A feature is ready to GA after it is Feature Complete and has obtained all necessary Focal Point Approvals.
Feature Complete
Feature implementation and tests completed.
All PRs are merged.
All epic and child issues are closed.
All stop ship issues are completed.
Legal: all necessary approvals granted.
Translation: All messages translated or sent for translation for upcoming release
GA development complete and feature ready for inclusion in a GA release
Add label target:ga and the appropriate target:YY00X (where YY00X is the targeted GA version).
Inclusion in a release requires the completion of all Focal Point Approvals.
Focal Point Approvals (Complete by Feature Complete Date)
These occur only after GA of this feature is requested (by adding a target:ga label). GA of this feature may not occur until all approvals are obtained.
NOTE: If only trivial documentation changes are required, you may reach out to the ID Feature Focal to request a ID Required - Trivial label. Unlike features with regular ID requirement, those with ID Required - Trivial label do not have a hard requirement for a Design/UFO.
Add a link to the GA Blog issue in the Documents section.
Note: This is for inclusion into the overall release blog post. If, in addition, you'd also like to create a dedicated blog post about your feature, then follow the "Standalone Feature Blog Post" instructions under the Other Deliverables section.
Description
In general response codes in the 400 and 500 range are errors so keeping persistent http connections open would pose issues with the requirements of persistent connections. However some 400 codes, like 404, can be safely sent without closing the connection. This feature is to investigate a design that allows us to keep using a connection with those errors. For traditional http a 404 is a rare occurrence, but when http is used for computer to computer interaction a 404 is more likely to be normal with the creation of a new connection being an overhead if many requests are being made.
Documents
When available, add links to required feature documents. Use "N/A" to mark particular documents which are not required by the feature.
Process Overview
General Instructions
The process steps occur roughly in the order as presented. Process steps occasionally overlap.
Each process step has a number of tasks which must be completed or must be marked as not applicable ("N/A").
Unless otherwise indicated, the tasks are the responsibility of the Feature Owner or a Delegate of the Feature Owner.
If you need assistance, reach out to the OpenLiberty/release-architect.
Important: Labels are used to trigger particular steps and must be added as indicated.
Prioritization (Complete Before Development Starts)
The (OpenLiberty/chief-architect) and area leads are responsible for prioritizing the features and determining which features are being actively worked on.
Prioritization
Design (Complete Before Development Starts)
Design preliminaries determine whether a formal design, which will be provided by an Upcoming Feature Overview (UFO) document, must be created and reviewed. A formal design is required if the feature requires any of the following: UI, Serviceability, SVT, Performance testing, or non-trivial documentation/ID.
Design Preliminaries
ID Required
, if non-trivial documentation needs to be created by the ID team.ID Required - Trivial
, if no design will be performed and only trivial ID updates are needed.Design
Design Review Request
Design Approval Request
Design Approved
No Design
No Design Approval Request
No Design Approved
Product Management Approval Request
and notifies OpenLiberty/product-managementProduct Management Approved
(OpenLiberty/product-management)FAT Documentation
Implementation
A feature must be prioritized before any implementation work may begin to be delivered (inaccessible/no-ship). However, a design focused approach should still be applied to features, and developers should think about the feature design prior to writing and delivering any code.
Besides being prioritized, a feature must also be socialized (or No Design Approved) before any beta code may be delivered. All new Liberty content must be inaccessible in our GA releases until it is Feature Complete by either marking it
kind=noship
or beta fencing it.Code may not GA until this feature has obtained the "Design Approved" or "No Design Approved" label, along with all other tasks outlined in the GA section.
Feature Development Begins
In Progress
labelLegal and Translation
In order to avoid last minute blockers and significant disruptions to the feature, the legal items need to be done as early in the feature process as possible, either in design or as early into the development as possible. Similarly, translation is to be done concurrently with development. Both MUST be completed before Beta or GA is requested.
Legal (Complete before Feature Complete Date)
Translation (Complete 1 week before Feature Complete Date)
Innovation (Complete 1 week before Feature Complete Date)
Beta
In order to facilitate early feedback from users, all new features and functionality should first be released as part of a beta release.
Beta Code
kind=beta
,ibm:beta
,ProductInfo.getBetaEdition()
target:beta
and the appropriatetarget:YY00X-beta
(where YY00X is the targeted beta version).release:YY00X-beta
(where YY00X is the first beta version that included the functionality).Beta Blog (Complete 1.5 weeks before beta eGA)
GA
A feature is ready to GA after it is Feature Complete and has obtained all necessary Focal Point Approvals.
Feature Complete
target:ga
and the appropriatetarget:YY00X
(where YY00X is the targeted GA version).Focal Point Approvals (Complete by Feature Complete Date)
These occur only after GA of this feature is requested (by adding a
target:ga
label). GA of this feature may not occur until all approvals are obtained.All Features
focalApproved:externals
@OpenLiberty/demo-approvers Demo scheduled for EOI [Iteration Number]
to this issue.focalApproved:demo
.focalApproved:fat
.focalApproved:globalization
.Design Approved Features
focalApproved:accessibility
.focalApproved:id
.focalApproved:performance
.focalApproved:sve
.focalApproved:ste
.focalApproved:svt
.Remove Beta Fencing (Complete by Feature Complete Date)
GA Blog (Complete by Feature Complete Date)
Post GA
target:YY00X
label with the appropriaterelease:YY00X
. (OpenLiberty/release-manager)Other Deliverables
The text was updated successfully, but these errors were encountered: