Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tier Renaming #319

Open
wants to merge 6 commits into
base: main
Choose a base branch
from
Open

Tier Renaming #319

wants to merge 6 commits into from

Conversation

beekhof
Copy link
Collaborator

@beekhof beekhof commented Oct 3, 2023

  • Rename community to sandbox
  • Rename validated to maintained
  • Create tested as a mid-point
  • Old urls should still map to the new content
  • Renaming the badges is left for a subsequent PR
  • Reviewing the second commit might be more useful than the combined PR

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Oct 3, 2023

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: beekhof

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-merge-robot
Copy link
Contributor

PR needs rebase.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

Copy link

@atherr atherr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is difficult for our core capabilities to meet these standards. ESO and the patterns operator are not supported (or easily substituted for supportable equivalents). AEGO does not have a presentation deck.

If we add in ESO to the bottom of the must section, by the statement "The validated patterns team is very motivated to address any problems in the VP Operator and ESO"... that might help.

@beekhof beekhof force-pushed the tiers branch 6 times, most recently from 932aca3 to 205e086 Compare October 10, 2023 00:21
Copy link
Contributor

@mbaldessari mbaldessari left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the idea the we have three layers in the end: maintained, sandbox and tested? Or is it just due to this being WIP?

@@ -13,7 +13,7 @@ industries:
links:
install:
arch:
help: https://groups.google.com/g/hybrid-cloud-patterns
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I took the liberty of fixing those via #324 since the old group was already returning "content unavailable"

[id="tldr"]
== tl;dr

The Maintained tier is intended to provide consumers with additional "sales" collateral and reassurance that the pattern was known to be functional on all currently supported LTS versions of OpenShift. Inclusion in this tier may require additional work for the pattern's owner - which might be a partner or sufficiently motivated SME.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd avoid using the LTS expression since Red Hat almost never uses that. Did you really meant LTS as in EUS or as in whatever OCP is supported?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I meant EUS

. Maintained Patterns *MUST* conform to the common technical link:/requirements/implementation/[implementation requirements]
. Maintained Patterns *MUST* only make use of components that are either supported, or easily substitued for supportable equivalents (eg. HashiCorp vault which has community and enterprise variants)
. Maintained Patterns *MUST NOT* rely on functionality in tech-preview, or hidden behind feature gates
. Maintained Patterns *MUST* have their architectures reviewed by the PM, TPM, or TMM of each Red Hat product they consume to ensure consistency with the product teams` intentions and roadmaps
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't know, this feels like an especially heavy burden, not only on Pattern's authors, but also on the *PM/*TMM on the other side of the fence. Maybe a should is more appropriate here?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remember this is for maintained patterns. There should be fewer, and the burden should be higher.

. Sandbox Patterns *MUST* conform to the common technical link:/requirements/implementation/[implementation requirements]
. Tested Patterns *MUST* be able to be deployed onto a freshly deployed OpenShift cluster without prior modification or tuning
. Sandbox Patterns *MUST* include a top-level README highlighting the business problem and how the pattern solves it
. Sandbox Patterns *MUST* include an architecture drawing. The specific tool/format is flexible as long as the meaning is clear.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would go for a should here

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems a bit onerous to me

. Tested Patterns *MUST* be able to be deployed onto a freshly deployed OpenShift cluster without prior modification or tuning
. Sandbox Patterns *MUST* include a top-level README highlighting the business problem and how the pattern solves it
. Sandbox Patterns *MUST* include an architecture drawing. The specific tool/format is flexible as long as the meaning is clear.
. Sandbox Patterns *MUST* undergo an informal technical review by a community leader to ensure that it meets basic reuse standards
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should probably define "community leader" a bit better here. It's not entirely obvious

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

somewhat deliberate

= The Validated Patterns 'Maintained' Tier

[id="tldr"]
== tl;dr
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe Summary ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could be. this is what the current pages used

content/learn/tested.adoc Show resolved Hide resolved
@beekhof
Copy link
Collaborator Author

beekhof commented Oct 10, 2023

Is the idea the we have three layers in the end: maintained, sandbox and tested? Or is it just due to this being WIP?

yes, we want three levels (+ archived).
sandbox ~= community
maintained ~= validated
tested is inbetween

@beekhof
Copy link
Collaborator Author

beekhof commented Oct 10, 2023

It is difficult for our core capabilities to meet these standards. ESO and the patterns operator are not supported (or easily substituted for supportable equivalents). AEGO does not have a presentation deck.

Are you arguing for lowering the standards, or getting our house in order?

If we add in ESO to the bottom of the must section, by the statement "The validated patterns team is very motivated to address any problems in the VP Operator and ESO"... that might help.

@mbaldessari
Copy link
Contributor

Is the idea the we have three layers in the end: maintained, sandbox and tested? Or is it just due to this being WIP?

yes, we want three levels (+ archived). sandbox ~= community maintained ~= validated tested is inbetween

Ack, I like that we kept the list of different levels somewhat small. +1 in general

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants