From 6e61aa84d66ad1f6fdf87628780420211b97d21b Mon Sep 17 00:00:00 2001 From: Jeff Mesnil Date: Thu, 27 Jun 2024 11:12:43 +0200 Subject: [PATCH 1/6] Update template and checks * Update the template to move the tracking issue and the stability level to the front matter * When a PR is open, check that these fields are valid * Generate a HTML page for the proposal with these fields. Signed-off-by: Jeff Mesnil --- .scripts/check_proposals | 33 +++++++++ _includes/index-categories.html | 8 ++- _layouts/proposal.html | 10 ++- design-doc-template.adoc | 123 ++++++++++++-------------------- 4 files changed, 95 insertions(+), 79 deletions(-) diff --git a/.scripts/check_proposals b/.scripts/check_proposals index 594ab165..6a134d66 100755 --- a/.scripts/check_proposals +++ b/.scripts/check_proposals @@ -37,6 +37,21 @@ class MetadataChecker else system("gh pr edit #{pr_number} --remove-label invalid-categories") end + issue_errors = check_issue(pr_number, front_matter) + if issue_errors.length() > 0 + errors << issue_errors + system("gh pr edit #{pr_number} --add-label missing-issue") + else + system("gh pr edit #{pr_number} --remove-label missing-issue") + end + stability_level_error = check_stability_level(pr_number, front_matter) + if stability_level_error.length() > 0 + errors << stability_level_error + system("gh pr edit #{pr_number} --add-label invalid-stability-level") + else + system("gh pr edit #{pr_number} --remove-label invalid-stability-level") + end + errors end @@ -54,6 +69,24 @@ class MetadataChecker errors end + def check_issue pr_number, front_matter + errors = [] + unless (front_matter.key? "issue") && (front_matter["issue"] != nil) + errors << "Missing field: issue" + end + errors + end + + def check_stability_level pr_number, front_matter + stability_levels = ["experimental", "preview", "community", "default"] + + errors = [] + unless (front_matter.key? "stability-level") && (stability_levels.include? front_matter["stability-level"]) + errors << "Invalid field: stability-level" + end + errors + end + def load_all_categories yaml = YAML.load_file("_data/wildfly-categories.yaml") return yaml["categories"] diff --git a/_includes/index-categories.html b/_includes/index-categories.html index bbddadac..4bf3fd47 100644 --- a/_includes/index-categories.html +++ b/_includes/index-categories.html @@ -28,7 +28,13 @@

{{ cat.name }} [{{ cat.id }}]

{% for page in site.pages %} {% endfor %} diff --git a/_layouts/proposal.html b/_layouts/proposal.html index 4b7cfa1a..4f51cec0 100644 --- a/_layouts/proposal.html +++ b/_layouts/proposal.html @@ -4,7 +4,12 @@
-

{{page.title}}

+

+ {% if page.stability-level != "default" or page.stability-level != "community" %} + [{{ page.stability-level }}]  + {% endif %} + {{page.title}} +

{% unless pages.categories == empty %} @@ -14,6 +19,9 @@

{{page.title}}

{% endfor %}
{% endunless %} +
Tracked by  + {{ page.issue }} +
{{ content }}
diff --git a/design-doc-template.adoc b/design-doc-template.adoc index e0ce62b1..4b6bd049 100644 --- a/design-doc-template.adoc +++ b/design-doc-template.adoc @@ -4,8 +4,16 @@ categories: # - core # - management # if missing, add it to _data/widfly-categories and use its id +# +# Specify the stability level of the feature. +# Values can be one of: experimental preview community default +stability-level: +# Specify the main issue of the feature +# Most of the time, it will be a issue in https://issues.redhat.com/browse/WFLY +# or https://issues.redhat.com/browse/WFCORE +issue: --- -= [Experimental|Preview|Community|default]Template += :author: Your Name :email: your.email@redhat.com :toc: left @@ -13,95 +21,63 @@ categories: :idprefix: :idseparator: - -== Overview - -== Issue Metadata - -=== Issue - -* https://issues.redhat.com/browse/WFCORE[WFCORE-XXXX] - -=== Related Issues - -* https://issues.redhat.com/browse/WFLY[WFLY-XXXX] - -=== Stability Level -// Choose the planned stability level for the proposed functionality -* [ ] Experimental - -* [ ] Preview +____ -* [ ] Community - -* [ ] default - -=== Dev Contacts - -* mailto:{email}[{author}] +== Overview -=== QE Contacts +____ -=== Testing By -// Put an x in the relevant field to indicate if testing will be done by Engineering or QE. -// Discuss with QE during the Kickoff state to decide this -* [ ] Engineering -* [ ] QE +== Affected Projects or Components -=== Affected Projects or Components +____ === Other Interested Projects === Relevant Installation Types -// Remove the x next to the relevant field if the feature in question is not relevant -// to that kind of WildFly installation -* [x] Traditional standalone server (unzipped or provisioned by Galleon) -* [x] Managed domain +____. -* [x] OpenShift s2i - -* [x] Bootable jar +* Traditional standalone server (unzipped or provisioned by Galleon) +* Managed domain +* OpenShift Source-to-Image (S2I) +* Bootable jar == Requirements -=== Hard Requirements - -=== Nice-to-Have Requirements -// Requirements in this section do not have to be met to merge the proposed functionality. -// Note: Nice-to-have requirements that don't end up being implemented as part of -// the work covered by this proposal should be moved to the 'Future Work' section. - +____ === Non-Requirements -// Use this section to explicitly discuss things that readers might think are required -// but which are not required. + +____ === Future Work -// Use this section to discuss requirements that are not addressed by this proposal -// but which may be addressed in later proposals. + +____ == Backwards Compatibility -// Does this enhancement affect backwards compatibility with previously released -// versions of WildFly? -// Can the identified incompatibility be avoided? +____ === Default Configuration +____ + === Importing Existing Configuration +____ + === Deployments +____ + === Interoperability -//== Implementation Plan -//// -Delete if not needed. The intent is if you have a complex feature which can -not be delivered all in one go to suggest the strategy. If your feature falls -into this category, please mention the Release Coordinators on the pull -request so they are aware. -//// +____ + +== Implementation Plan + +____ == Admin Clients @@ -109,14 +85,11 @@ ____ == Test Plan -Depending on the selected stability level, the appropriate section below should be completed, including a brief description of how testing is to be performed in accordance with the selected stability level. The non-relevant sections may be removed as needed. +____ //// Depending on the stability level, the test plan required may vary. see below: //// @@ -134,16 +107,12 @@ Depending on the stability level, the test plan required may vary. see below: ** Default - This stability level is reserved and requires approval by a professional Quality Engineer with subject matter expertise. == Community Documentation -//// -Generally a feature should have documentation as part of the PR to wildfly main, or as a follow up PR if the feature is in wildfly-core. In some cases though the documentation belongs more in a component, or does not need any documentation. Indicate which of these will happen. -//// + +____ + +** Default - This stability level is reserved and requires approval by a professional Quality Engineer with subject matter expertise. + == Release Note Content -//// -Draft verbiage for up to a few sentences on the feature for inclusion in the -Release Note blog article for the release that first includes this feature. -Example article: http://wildfly.org/news/2018/08/30/WildFly14-Final-Released/. -This content will be edited, so there is no need to make it perfect or discuss -what release it appears in. "See Overview" is acceptable if the overview is -suitable. For simple features best covered as an item in a bullet-point list -of features containing a few words on each, use "Bullet point: " -//// + +____ From caae72f1641e2a9936ce1fd6471406052b6c7116 Mon Sep 17 00:00:00 2001 From: Jeff Mesnil Date: Thu, 4 Jul 2024 08:44:44 +0200 Subject: [PATCH 2/6] Add labels for the stability-levels Based on the value of the `stability-level` field in the front matter, add a label `stability-level/xxx` to the PR. Signed-off-by: Jeff Mesnil --- .scripts/check_proposals | 25 ++++++++++++++----------- 1 file changed, 14 insertions(+), 11 deletions(-) diff --git a/.scripts/check_proposals b/.scripts/check_proposals index 6a134d66..7ee64684 100755 --- a/.scripts/check_proposals +++ b/.scripts/check_proposals @@ -25,6 +25,7 @@ end class MetadataChecker def initialize @categories = load_all_categories() + @stability_levels = ["experimental", "preview", "community", "default"] end def check pr_number, front_matter @@ -44,12 +45,16 @@ class MetadataChecker else system("gh pr edit #{pr_number} --remove-label missing-issue") end - stability_level_error = check_stability_level(pr_number, front_matter) - if stability_level_error.length() > 0 - errors << stability_level_error - system("gh pr edit #{pr_number} --add-label invalid-stability-level") - else + begin + stability_level, err = check_stability_level(pr_number, front_matter) system("gh pr edit #{pr_number} --remove-label invalid-stability-level") + # remove any previous stability-levels + @stability_levels.map { | level | system("gh pr edit #{pr_number} --remove-label stability-level/#{level}") } + system("gh pr edit #{pr_number} --add-label stability-level/#{stability_level}") + rescue => error + errors << error.message + system("gh pr edit #{pr_number} --add-label invalid-stability-level") + @stability_levels.map { | level | system("gh pr edit #{pr_number} --remove-label stability-level/#{level}") } end errors @@ -78,13 +83,11 @@ class MetadataChecker end def check_stability_level pr_number, front_matter - stability_levels = ["experimental", "preview", "community", "default"] - - errors = [] - unless (front_matter.key? "stability-level") && (stability_levels.include? front_matter["stability-level"]) - errors << "Invalid field: stability-level" + unless (front_matter.key? "stability-level") && (@stability_levels.include? front_matter["stability-level"]) + raise "Invalid field: stability-level" + else + return front_matter["stability-level"] end - errors end def load_all_categories From afd7f2ecf33ce3820e146aac679999413b9522e6 Mon Sep 17 00:00:00 2001 From: Jeff Mesnil Date: Fri, 4 Oct 2024 09:23:39 +0200 Subject: [PATCH 3/6] Update template * bring back Related Issues sections * clarify the issue metadata semantic Signed-off-by: Jeff Mesnil --- _layouts/proposal.html | 2 +- design-doc-template.adoc | 10 +++++++--- 2 files changed, 8 insertions(+), 4 deletions(-) diff --git a/_layouts/proposal.html b/_layouts/proposal.html index 4f51cec0..c68b75dc 100644 --- a/_layouts/proposal.html +++ b/_layouts/proposal.html @@ -19,7 +19,7 @@

{% endfor %}

{% endunless %} -
Tracked by  +
Tracked by {{ page.issue }}
diff --git a/design-doc-template.adoc b/design-doc-template.adoc index 4b6bd049..a2955f60 100644 --- a/design-doc-template.adoc +++ b/design-doc-template.adoc @@ -8,9 +8,10 @@ categories: # Specify the stability level of the feature. # Values can be one of: experimental preview community default stability-level: -# Specify the main issue of the feature -# Most of the time, it will be a issue in https://issues.redhat.com/browse/WFLY -# or https://issues.redhat.com/browse/WFCORE +#Specify the Feature Development tracker issue for the feature. +# This must be an issue tracked in https://github.com/orgs/wildfly/projects/7/views/1. +# To create a Feature Development tracker issue, go to https://github.com/wildfly/wildfly-proposals/issues/new/choose +# and select 'Feature Development' issue: --- = @@ -27,6 +28,9 @@ ____ +== Related Issues + +____ == Affected Projects or Components From 10fb0514feb9880b726a476d15f328062cd41890 Mon Sep 17 00:00:00 2001 From: Jeff Mesnil Date: Fri, 4 Oct 2024 09:25:16 +0200 Subject: [PATCH 4/6] Display community stability-level Signed-off-by: Jeff Mesnil --- _includes/index-categories.html | 2 +- _layouts/proposal.html | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/_includes/index-categories.html b/_includes/index-categories.html index 4bf3fd47..87194629 100644 --- a/_includes/index-categories.html +++ b/_includes/index-categories.html @@ -29,7 +29,7 @@

{{ cat.name }} [{{ cat.id }}]

    {% if page.categories contains cat.id %}
  • - {% if page.stability-level != "default" or page.stability-level != "community" %} + {% if page.stability-level != "default" %} [{{ page.stability-level }}]  {% endif %} diff --git a/_layouts/proposal.html b/_layouts/proposal.html index c68b75dc..f256fedc 100644 --- a/_layouts/proposal.html +++ b/_layouts/proposal.html @@ -5,7 +5,7 @@

    - {% if page.stability-level != "default" or page.stability-level != "community" %} + {% if page.stability-level != "default" %} [{{ page.stability-level }}]  {% endif %} {{page.title}} From 4b59208ce366fd974ac8c408124f3337a713342d Mon Sep 17 00:00:00 2001 From: Brian Stansberry Date: Wed, 9 Oct 2024 13:07:18 -0500 Subject: [PATCH 5/6] Fix some rendering issues; use generated stability info for already merged proposals --- _includes/index-categories.html | 4 ++-- _layouts/proposal.html | 6 +++--- build/WFLY-19130_publish_Wildfly_channel_manifest.adoc | 5 +++-- controller/WFCORE-4868_configuration-files-aliases.adoc | 3 ++- ...er_as_an_attachment_for_standalone_or_domain_mode.adoc | 3 ++- ...er_as_an_attachment_for_standalone_or_domain_mode.adoc | 3 ++- ee/WFLY-19062-[PREVIEW]-Support_for_Jakarta_MVC_2.1.adoc | 3 ++- elytron/WFLY-13762_ssl_context_based_on_peer_info.adoc | 3 ++- elytron/WFLY-16306-keycloak-saml-feature-pack.adoc | 4 ++++ elytron/WFLY-16532-additional-scope-for-auth-request.adoc | 6 ++++-- elytron/WFLY-17143-request-uri-parameters.adoc | 8 +++++++- server/WFCORE-6728-reload-to-stability-level.adoc | 3 ++- server/WFCORE-6750-unstable-api-annotation-scanner.adoc | 3 ++- ...WFCORE-6815-reload-domain-mode-to-stability-level.adoc | 3 ++- ...ake_resuseXForwarded_and_rewriteHost_configurable.adoc | 7 ++++++- .../WFLY-15452_ajp-listener_allowed_attr_pattern.adoc | 7 ++++++- wf-galleon/WFLY-19021-Stability_In_Provisioning.adoc | 3 ++- 17 files changed, 53 insertions(+), 21 deletions(-) diff --git a/_includes/index-categories.html b/_includes/index-categories.html index 87194629..35c48dc8 100644 --- a/_includes/index-categories.html +++ b/_includes/index-categories.html @@ -29,8 +29,8 @@

    {{ cat.name }} [{{ cat.id }}]

      {% if page.categories contains cat.id %}
    • - {% if page.stability-level != "default" %} - [{{ page.stability-level }}]  + {% if page.stability-level != nil and page.stability-level != "default" %} + [{{ page.stability-level | upcase }}]  {% endif %} {{ page.title }} diff --git a/_layouts/proposal.html b/_layouts/proposal.html index f256fedc..518a9c86 100644 --- a/_layouts/proposal.html +++ b/_layouts/proposal.html @@ -5,8 +5,8 @@

      - {% if page.stability-level != "default" %} - [{{ page.stability-level }}]  + {% if page.stability-level != nil and page.stability-level != "default" %} + [{{ page.stability-level | upcase }}]  {% endif %} {{page.title}}

      @@ -20,7 +20,7 @@

      {% endunless %}       {{ content }} diff --git a/build/WFLY-19130_publish_Wildfly_channel_manifest.adoc b/build/WFLY-19130_publish_Wildfly_channel_manifest.adoc index b8ac19d4..237eeccf 100644 --- a/build/WFLY-19130_publish_Wildfly_channel_manifest.adoc +++ b/build/WFLY-19130_publish_Wildfly_channel_manifest.adoc @@ -2,8 +2,9 @@ categories: - wf-galleon - maven +stability-level: community --- -= [Community] Publish WildFly channel manifest += Publish WildFly channel manifest :author: Bartosz Spyrko-Smietanko :email: bspyrkos@redhat.com :toc: left @@ -131,7 +132,7 @@ Following three channels will be created as part of this proposal: |=== -==== Manifest metadata Requirements +=== Manifest metadata Requirements The manifest file defines a few metadata fields: * name - human readable name of the manifest. Should contain the version of the server. diff --git a/controller/WFCORE-4868_configuration-files-aliases.adoc b/controller/WFCORE-4868_configuration-files-aliases.adoc index f73c34d2..9b44160b 100644 --- a/controller/WFCORE-4868_configuration-files-aliases.adoc +++ b/controller/WFCORE-4868_configuration-files-aliases.adoc @@ -2,8 +2,9 @@ categories: - core - management +stability-level: community --- -= [Community] Aliases for standard configuration files += Aliases for standard configuration files :author: Michal Petrov :email: mpetrov@redhat.com :toc: left diff --git a/core/WFCORE-4758_Simple_config_export_for_a_server_as_an_attachment_for_standalone_or_domain_mode.adoc b/core/WFCORE-4758_Simple_config_export_for_a_server_as_an_attachment_for_standalone_or_domain_mode.adoc index 1c0a5fa1..5d8c4b3e 100644 --- a/core/WFCORE-4758_Simple_config_export_for_a_server_as_an_attachment_for_standalone_or_domain_mode.adoc +++ b/core/WFCORE-4758_Simple_config_export_for_a_server_as_an_attachment_for_standalone_or_domain_mode.adoc @@ -2,8 +2,9 @@ categories: - core - management +stability-level: community --- -= [Community] Simple config export for a server as an attachment for standalone or domain mode += Simple config export for a server as an attachment for standalone or domain mode :author: Emmanuel Hugonnet :email: ehugonne@redhat.com :toc: left diff --git a/core/WFCORE-6960_Simple_config_export_for_a_server_as_an_attachment_for_standalone_or_domain_mode.adoc b/core/WFCORE-6960_Simple_config_export_for_a_server_as_an_attachment_for_standalone_or_domain_mode.adoc index e478aaa6..e9eb5118 100644 --- a/core/WFCORE-6960_Simple_config_export_for_a_server_as_an_attachment_for_standalone_or_domain_mode.adoc +++ b/core/WFCORE-6960_Simple_config_export_for_a_server_as_an_attachment_for_standalone_or_domain_mode.adoc @@ -2,8 +2,9 @@ categories: - core - management +stability-level: default --- -= [Community] Simple config export for a server as an attachment for standalone or domain mode += Simple config export for a server as an attachment for standalone or domain mode :author: Emmanuel Hugonnet :email: ehugonne@redhat.com :toc: left diff --git a/ee/WFLY-19062-[PREVIEW]-Support_for_Jakarta_MVC_2.1.adoc b/ee/WFLY-19062-[PREVIEW]-Support_for_Jakarta_MVC_2.1.adoc index e613ed0a..b46e5416 100644 --- a/ee/WFLY-19062-[PREVIEW]-Support_for_Jakarta_MVC_2.1.adoc +++ b/ee/WFLY-19062-[PREVIEW]-Support_for_Jakarta_MVC_2.1.adoc @@ -1,8 +1,9 @@ --- categories: - ee +stability-level: preview --- -= [Preview] Standard WildFly support for Jakarta MVC 2.1 += Standard WildFly support for Jakarta MVC 2.1 :author: Brian Stansberry :email: brian.stansberry@redhat.com :toc: left diff --git a/elytron/WFLY-13762_ssl_context_based_on_peer_info.adoc b/elytron/WFLY-13762_ssl_context_based_on_peer_info.adoc index 216674ac..2db49682 100644 --- a/elytron/WFLY-13762_ssl_context_based_on_peer_info.adoc +++ b/elytron/WFLY-13762_ssl_context_based_on_peer_info.adoc @@ -2,8 +2,9 @@ categories: - elytron - security +stability-level: community --- -= [Community] SSLContext to support delegation to alternate instances based on peer information += SSLContext to support delegation to alternate instances based on peer information :author: Diana Krepinska :email: dvilkola@redhat.com :toc: left diff --git a/elytron/WFLY-16306-keycloak-saml-feature-pack.adoc b/elytron/WFLY-16306-keycloak-saml-feature-pack.adoc index 9df92f60..fc09e3f8 100644 --- a/elytron/WFLY-16306-keycloak-saml-feature-pack.adoc +++ b/elytron/WFLY-16306-keycloak-saml-feature-pack.adoc @@ -1,3 +1,7 @@ +--- +categories: + - security +--- = WFLY-16306: Keycloak Galleon Feature Pack :author: Farah Juma :email: fjuma@redhat.com diff --git a/elytron/WFLY-16532-additional-scope-for-auth-request.adoc b/elytron/WFLY-16532-additional-scope-for-auth-request.adoc index 2b94235f..9cf713b5 100644 --- a/elytron/WFLY-16532-additional-scope-for-auth-request.adoc +++ b/elytron/WFLY-16532-additional-scope-for-auth-request.adoc @@ -1,8 +1,10 @@ --- categories: - - elytron + - elytron + - security +stability-level: preview --- -== [Preview] Adding the ability to configure additional scope value for an authentication request += Adding the ability to configure additional scope value for an authentication request :author: Prarthona Paul :email: prpaul@redhat.com :toc: left diff --git a/elytron/WFLY-17143-request-uri-parameters.adoc b/elytron/WFLY-17143-request-uri-parameters.adoc index b5b6e1f3..d43e999f 100644 --- a/elytron/WFLY-17143-request-uri-parameters.adoc +++ b/elytron/WFLY-17143-request-uri-parameters.adoc @@ -1,4 +1,10 @@ -= [Preview] Add the ability to specify that the OIDC Authentication Request should include request and request_uri parameters +--- +categories: + - elytron + - security +stability-level: preview +--- += Add the ability to specify that the OIDC Authentication Request should include request and request_uri parameters :author: Prarthona Paul :email: prpaul@redhat.com :toc: left diff --git a/server/WFCORE-6728-reload-to-stability-level.adoc b/server/WFCORE-6728-reload-to-stability-level.adoc index 5e30a011..e0dbc19e 100644 --- a/server/WFCORE-6728-reload-to-stability-level.adoc +++ b/server/WFCORE-6728-reload-to-stability-level.adoc @@ -4,8 +4,9 @@ categories: - management # Add any category for this proposal # if missing, add it to _data/widfly-categories and use its id +stability-level: community --- -= [Community] Ability to reload a server to a different stability level += Ability to reload a server to a different stability level :author: Kabir Khan :email: kkhan@redhat.com :toc: left diff --git a/server/WFCORE-6750-unstable-api-annotation-scanner.adoc b/server/WFCORE-6750-unstable-api-annotation-scanner.adoc index 941f9ce8..3bfe9e2c 100644 --- a/server/WFCORE-6750-unstable-api-annotation-scanner.adoc +++ b/server/WFCORE-6750-unstable-api-annotation-scanner.adoc @@ -5,8 +5,9 @@ categories: # Add any category for this proposal # if missing, add it to _data/widfly-categories and use its id +stability-level: preview --- -= [Preview] Scan for usage of API elements annotated with annotations indicating unstable API += Scan for usage of API elements annotated with annotations indicating unstable API :author: Kabir Khan :email: kkhan@redhat.com :toc: left diff --git a/server/WFCORE-6815-reload-domain-mode-to-stability-level.adoc b/server/WFCORE-6815-reload-domain-mode-to-stability-level.adoc index df59f89b..947482b8 100644 --- a/server/WFCORE-6815-reload-domain-mode-to-stability-level.adoc +++ b/server/WFCORE-6815-reload-domain-mode-to-stability-level.adoc @@ -4,8 +4,9 @@ categories: - management # Add any category for this proposal # if missing, add it to _data/widfly-categories and use its id +stability-level: community --- -= [Community] Ability to reload a Host Controller to a different stability level += Ability to reload a Host Controller to a different stability level :author: Yeray Borges :email: yborgess@redhat.com :toc: left diff --git a/undertow/WFLY-14255_Make_resuseXForwarded_and_rewriteHost_configurable.adoc b/undertow/WFLY-14255_Make_resuseXForwarded_and_rewriteHost_configurable.adoc index 709cb1eb..27d336e9 100644 --- a/undertow/WFLY-14255_Make_resuseXForwarded_and_rewriteHost_configurable.adoc +++ b/undertow/WFLY-14255_Make_resuseXForwarded_and_rewriteHost_configurable.adoc @@ -1,4 +1,9 @@ -= [Preview]Make ReuseXForwarded and RewriteHost configurable +--- +categories: + - undertow +stability-level: preview +--- += Make ReuseXForwarded and RewriteHost configurable :author: Bartosz Baranowski :email: bbaranow@redhat.com :toc: left diff --git a/undertow/WFLY-15452_ajp-listener_allowed_attr_pattern.adoc b/undertow/WFLY-15452_ajp-listener_allowed_attr_pattern.adoc index 31e50735..8d627a5b 100644 --- a/undertow/WFLY-15452_ajp-listener_allowed_attr_pattern.adoc +++ b/undertow/WFLY-15452_ajp-listener_allowed_attr_pattern.adoc @@ -1,4 +1,9 @@ -= [Preview]modify ajp-listener to allow specifying pattern for ajp request attributes +--- +categories: + - undertow +stability-level: preview +--- += Modify ajp-listener to allow specifying pattern for ajp request attributes :author: Bartosz Baranowski :email: bbaranow@redhat.com :toc: left diff --git a/wf-galleon/WFLY-19021-Stability_In_Provisioning.adoc b/wf-galleon/WFLY-19021-Stability_In_Provisioning.adoc index e942c936..4e777ddf 100644 --- a/wf-galleon/WFLY-19021-Stability_In_Provisioning.adoc +++ b/wf-galleon/WFLY-19021-Stability_In_Provisioning.adoc @@ -1,8 +1,9 @@ --- categories: - wf-galleon +stability-level: community --- -= [Community] WildFly provisioning to support WildFly stability += WildFly provisioning to support WildFly stability :author: Jean-Francois Denise :email: jdenise@redhat.com :toc: left From 99d3b8a134916c65041310c000cb99ba4cad82c9 Mon Sep 17 00:00:00 2001 From: Brian Stansberry Date: Sun, 29 Sep 2024 22:33:40 -0500 Subject: [PATCH 6/6] Beef up the feature process doc; add more metadata to the design doc template --- FEATURE_PROCESS.adoc | 157 +++++++++++++++++++++++++++++++++++---- _layouts/proposal.html | 5 +- design-doc-template.adoc | 77 ++++++++++++++----- 3 files changed, 204 insertions(+), 35 deletions(-) diff --git a/FEATURE_PROCESS.adoc b/FEATURE_PROCESS.adoc index cd8fa9bc..0959ad73 100644 --- a/FEATURE_PROCESS.adoc +++ b/FEATURE_PROCESS.adoc @@ -1,5 +1,133 @@ = WildFly Feature Development Process +The WildFly Feature Development Process defines the procedure that must be followed during the _development_ of features that appear in any of the following: + +* The standard WildFly distribution. +* The WildFly quickstarts. +* The WildFly Docker and OpenShift images. +* Standard end-user tooling documented for use with standard WildFly. +* WildFly Preview, if the feature is at `community` stability or higher. +* Feature packs that WildFly Glow suggests to users. (WildFly Glow may introduce the concept of "incubating" feature packs that users can opt into having Glow suggest. Development of such feature packs need not follow this process, but they *must not* provide features at `community` or higher stability). + +This process should be followed for: + +* The introduction of a feature at an initial stability level. +* Further feature development at the same stability level. +* AND for the promotion to another stability level. + +*_This process should be followed once a developer anticipates beginning work on a feature in the next three months._* The intent is to use the process to track active or soon-to-be-active development. + +NOTE: Requesting new features or recording ideas for new features are *not* part of this process. Feature requests are handled by simply filing an issue in the relevant project JIRA, typically https://issues.redhat.com/projects/WFLY/summary[WFLY, window=_blank]. + +== The Process + +Feature development proceeds in five stages: + +=== Kickoff + +When a developer intends to begin work on a feature they should do the following: + +* If one doesn't already exist, file an issue in the relevant project JIRA, typically https://issues.redhat.com/projects/WFLY/summary[WFLY, window=_blank], https://issues.redhat.com/projects/WFCORE/summary[WFCORE, window=_blank] or https://issues.redhat.com/projects/HAL/summary[HAL, window=_blank]. These issues are important as they allow users and developers to follow what has happened in a particular code base. +* [[planning_issue]]File an issue with the https://github.com/orgs/wildfly/projects/7[WildFly Feature Planning project, window=_blank]. To do this create an issue using the https://github.com/wildfly/wildfly-proposals/issues/new?assignees=&labels=feature&projects=wildfly%2F7&template=feature-development.yaml[Feature Development issue template, window=_blank]. This issue is important because: +** It is what allows effective coordination of overall feature development for a WildFly release from a single, publicly visible, point. +** It allows users to see an overall roadmap for WildFly features. +* Draft a minimal feature analysis, based on the current https://github.com/wildfly/wildfly-proposals/blob/main/design-doc-template.adoc[design-doc-template, window=_blank]. This should include the expected stability level, links to the issues above, and enough Overview and User Story information to give people interested in being part of the feature team a sense of what would be involved. +* Submit a draft analysis PR to the https://github.com/wildfly/wildfly-proposals[`wildfly-proposals` repository, window=_blank]. +* Send an email to the mailto:wildfly-dev@lists.jboss.org[`wildfly-dev@lists.jboss.org`] mail list telling people about the upcoming work and asking for volunteers to participate in the feature team. (If you don't have a `wildfly-dev` list subscription, visit the https://lists.jboss.org/admin/lists/wildfly-dev.lists.jboss.org/[list subscription page, window=_blank] to create one.) + +NOTE: All of the above are required, including new issues and analysis documents, even if the work being done is a promotion of an existing feature from one stability level to another. + +When the above tasks are complete, change the `Status` field of the WildFly Feature Planning project Issue to `Planning`. + +=== Planning + +The `Planning` stage of a feature consists of <> formation and enough discussion of the feature among the team that they can agree on a target feature stability level and target WildFly release in which they expect to *complete* the feature. + +NOTE: The target WildFly release is just a planning target and is not a commitment. + +Update the feature analysis document with the planned stability level (if it has changed) and the GitHub ids of the feature team members. + +If there is an available value that matches the target WildFly release, set the `Development Window` field in the <> to that value. + +NOTE: The expectation is there will always be `Development Window` values available for the next two WildFly releases. If teams expect to target a later release than that and there's no value available, that's ok; just don't set it. + +NOTE: If the feature team has discussed the target release but are uncertain and don't want to set a `Development Window` value until further work has been done, that's ok; just don't set it. + +When the above tasks are complete, change the `Status` field of the WildFly Feature Planning project Issue to `In Progress`. + +NOTE: Changes to the `Development Window` field of a WildFly Feature Planning project issue should always reflect the consensus of the feature team. + +=== In Progress + +The main work on the feature happens in this stage. The feature team works to meet the <> that apply to the feature's target stability. + +Feature teams are encouraged to engage in widely visible public discussion of their work, perhaps via a thread in `wildfly-dev@lists.jboss.org` or perhap via a thread in the https://wildfly.zulipchat.com/#narrow/stream/174184-wildfly-developers[Zulip `wildfly-developers` channel, window=_blank]. + +If, during the course development, the feature team changes their estimate of the target WildFly release when the feature will be completed, they should update the `Development Window` field in the <>. + +When the team has confirmed that all development work on the feature is complete and all <> are met, change the `Status` field of the <> to `Ready for Merge`. + +=== Ready for Merge + +An issue being in the `Ready for Merge` state indicates that the feature team has formally validated that the <> have been met. + +An issue being in this state is a signal to the release coordinator for the release and to the other WildFly mergers that the pull requests associated with the feature can be merged. + +=== Done + +The release coordinator moves the issue to `Done` status when all work associated with the feature has been merged. + +== Feature Promotion + +If a feature has been included in a WildFly release at a lower stability level and then a developer wishes to promote it to a higher stability level in a later release, the promotion should be done following the same processes as are followed for any other feature. There will of course be differences in the details of the work to be done, but the process steps are the same. + +=== Special Requirements for `preview` Stability + +When a feature is brought in at `preview` stability, this implies a commitment to our users that we expect to eventually move it to `community` stability or higher. To help ensure we keep that commitment, during development of the `preview` feature, the feature team should discuss with the leaders of the relevant technology area a rough plan for how that promotion will happen. Some information about that plan *must* appear in the `Future Work` section of the feature's analysis document. + +A primary goal here is to either identify a particular person who intends to carry the work forward, or at least get a commitment from a team that _someone_ will. A brief description of the expected future work will help clarify what may be required. + +There is no requirement to do this for `experimental` features, although developers are strongly discouraged from introducing experimental features they don't intend to personally take to at least `preview` if the experiment is successful. There is also no requirement to do this for `community` features, as `community` is a valid final stability level for a feature. + +[[feature-team]] +== The Feature Team + +A feature team consists of people in the following roles: + +=== Developer + +There is a single person in this role: the primary developer of the feature. Other members of the team may do development work, but the developer plays a leading role. + +=== Subject Matter Experts + +Multiple people can participate in this role. SMEs are knowledgeable in a technology area impacted by the feature. + +All feature teams must have at least one person in the Subject Matter Expert role. + +SMEs are expected to review all aspects of the feature analysis, implementation, test and documentation. + +=== Outside Perspective + +Multiple people can participate in this role. The Outside Perspective role is meant to serve three main purposes: + +* Attempt to bring a 'user' perspective to the feature team. The end user of the feature is unlikely to have anything close to the expertise of the Developer or a Subject Matter Expert, so things that seem understandable or intuitive to people in those roles may not be so for an end user. +* Attempt to avoid 'group think' in the development team. The feature may be being developed in accordance with existing plans by a team that does work in the feature's technical area, with the Developer and a Subject Matter Expert part of that team. There's nothing wrong with this, but it's useful to have someone involved who was not part of creating those plans. +* Perhaps bring a different kind of expertise to the team; for example expertise is usability design. + +Ideally a person in the Outside Perspective role would not be deeply knowledgeable in the feature's general technical area, although at times only people with some level of knowledge will be available. A person in the Outside Perspective role *must not* be someone who is part of a team that works in the feature's technical area. + +A person in the Outside Perspective role is not expected to do deep technical review of the feature implementation or tests. (Of course, they are welcome to do this if they choose.) They should focus on: + +* The Overview, User Stories and Requirements sections of the feature analysis. +* The feature documentation, including any ancillary material like quickstarts or user guides. +* Any end-user accessible API associated with the feature. +* For features at `community` stability or above, a person in the Outside Perspective role should perform manual verification of the feature (i.e. try it out). + +All feature teams for features at `preview` stability or higher must have at least one person in the Outside Perspective role. Features at `experimental` stability are not required to have anyone in the Outside Perspective role. However, once experimental features are in a release, if not before, authors of experimental features are expected to directly engage with the community to solicit feedback on their feature. + +[[requirements]] +== The Requirements + WildFly features can have one of four different maturity levels, “Experimental”, “Preview”, “Community” and an unnamed default level. Promotion from one level to another, or initial feature incorporation at a given level, requires meeting various standards in the basic areas of requirements analysis, implementation, testing and documentation. The following table outlines the various standards for each of the maturity levels. @@ -14,8 +142,9 @@ Promotion from one level to another, or initial feature incorporation at a given |Experimental plus: 3rd party with a different perspective, able to question the feature requirements and API -| same as Preview -| same as Community +| Same as Preview +| Same as Community +Involvement in SME or Outside Perspective roles by people with Quality Engineering and Technical Writing expertise //------- @@ -24,10 +153,9 @@ Promotion from one level to another, or initial feature incorporation at a given | Issue tracker with an understandable description with an orientation toward what/why and not just how |Approved WildFly Proposals document -Nice-to-have requirements allowed. -|Preview plus: +Future Work section describing a plan for promotion to Community. -Nice-to-have requirements have been converted to non-requirements or are moved to a future work section. +|Approved WildFly Proposals document |Same as Community //------- @@ -41,7 +169,7 @@ Management API has experimental metadata Feature not used at runtime if not in experimental level -New libraries not provisioned if not in appropriate stability level ??? +New libraries not provisioned if not in appropriate stability level Third party libraries in Final version?? |All hard requirements in analysis covered @@ -50,7 +178,7 @@ Management API has preview metadata Feature not used at runtime if not in preview level -New libraries not provisioned if not in appropriate stability level ??? +New libraries not provisioned if not in appropriate stability level |Stable API and behavior. All hard requirements in analysis covered @@ -59,7 +187,7 @@ Management API has community metadata Feature not used at runtime if not in community level -New libraries not provisioned if not in appropriate stability level ??? +New libraries not provisioned if not in appropriate stability level |Stable API and behavior All hard requirements in analysis covered @@ -116,9 +244,9 @@ Identified maintainer //------- | *Test Plan* -|Not required -|Required -- TODO what it means -|Same as Preview +|Not required. +|A brief high-level description of the testing approach should be provided, including types of tests added (unit, integration, smoke, component, subsystem, etc.) +|Preview plus descrption of the following additional testing as relevant: Manual tests, Miscellaneous checks, Integration tests, Compatibility tests. See https://docs.wildfly.org/wildfly-proposals/design-doc-template.html#test_plan[the design-doc-template, window=_blank] for details. |Community plus: Formal test plan approved by a professional Quality Engineer with subject matter expertise @@ -129,11 +257,11 @@ Formal test plan approved by a professional Quality Engineer with subject matter | *Test Development* |Standard subsystem tests. -Smoke tests of main functional areas. +Basic unit / integration tests of the main functional areas. |Standard subsystem tests. Test coverage as per test plan. -| Same as Experimental +| Same as Preview | Community plus: Domain transformation tests @@ -147,7 +275,7 @@ Domain transformation tests | Same as Preview | Community plus: -Verification by a professional Quality Engineer with subject matter expertise +Verification by a professional Quality Engineer with subject-matter expertise //------- @@ -163,3 +291,4 @@ Documentation content as per analysis. | Same as Community //------- |=== + diff --git a/_layouts/proposal.html b/_layouts/proposal.html index 518a9c86..26868ad7 100644 --- a/_layouts/proposal.html +++ b/_layouts/proposal.html @@ -12,17 +12,18 @@

      - {% unless pages.categories == empty %} + {% unless page.categories == nil or page.categories == empty %}
      In  {% for cat in page.categories %} {{ cat }} {% endfor %}
      {% endunless %} + {% unless page.issue == nil or page.issue == empty %}
      Tracked by {{ page.issue }}
      - + {% endunless %} {{ content }}
      diff --git a/design-doc-template.adoc b/design-doc-template.adoc index a2955f60..0fcb41b9 100644 --- a/design-doc-template.adoc +++ b/design-doc-template.adoc @@ -1,18 +1,34 @@ --- +// Add any category for this proposal as a yaml list, e.g. +// - core +// - management +// if missing, add it to _data/wildfly-categories and use its id categories: -# Add any category for this proposal as a yaml list, e.g. -# - core -# - management -# if missing, add it to _data/widfly-categories and use its id -# -# Specify the stability level of the feature. -# Values can be one of: experimental preview community default -stability-level: -#Specify the Feature Development tracker issue for the feature. -# This must be an issue tracked in https://github.com/orgs/wildfly/projects/7/views/1. -# To create a Feature Development tracker issue, go to https://github.com/wildfly/wildfly-proposals/issues/new/choose -# and select 'Feature Development' -issue: +// Specify the stability level of the feature. +// Values can be one of: experimental preview community default +stability-level: +// Specify the Feature Development tracker issue for the feature. +// This must be an issue tracked in https://github.com/orgs/wildfly/projects/7/views/1. +// To create a Feature Development tracker issue, go to https://github.com/wildfly/wildfly-proposals/issues/new/choose +// and select 'Feature Development' +issue: +// Provide the github ids of the members of the feature team, organized by role. +// Provide a single id for the 'assignee' role. Use a yaml list for the 'sme' and +// 'outside-perspective' roles, even if there is only one person in a role. +feature-team: + developer: + sme: + - + outside-perspective: + - +// If this issue tracks the promotion to a higher stability level of a previously +// completed feature, provide the URL of the https://github.com/wildfly/wildfly-proposals/issues +// issue that was used to track the previous feature. +promotes: +// This should be blank during initial development of a feature. It may be used +// after the feature is completed if a subsequent issue is field to track promotion +// of this feature to a higher stability level +promoted-by: --- = :author: Your Name @@ -28,11 +44,18 @@ ____ -== Related Issues +=== User Stories + +____ + +== Issue Metadata + +=== Related Issues ____ -== Affected Projects or Components +=== Affected Projects or Components ____ @@ -40,7 +63,7 @@ ____. +____. * Traditional standalone server (unzipped or provisioned by Galleon) * Managed domain @@ -49,7 +72,22 @@ ____ +____ + +____ + +=== Changed requirements + +____ + +____ + === Non-Requirements @@ -73,7 +111,7 @@ ____ +____ === Interoperability @@ -91,6 +129,7 @@ ____ +[[test_plan]] == Test Plan ____ @@ -98,7 +137,7 @@ __