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

Publish policy on using generics in gateway-api #1388

Open
keithmattix opened this issue Sep 14, 2022 · 6 comments
Open

Publish policy on using generics in gateway-api #1388

keithmattix opened this issue Sep 14, 2022 · 6 comments
Assignees
Labels
good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. kind/feature Categorizes issue or PR as related to a new feature. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale.

Comments

@keithmattix
Copy link
Contributor

keithmattix commented Sep 14, 2022

What would you like to be added:
With generics shipping in go1.18, the gateway-api project needs to have some kind of policy around when and how generics should be used. If upstream Kubernetes has a policy, we likely need to mirror it. If further discussion is needed, please use GitHub Discussions and/or Slack to engage members of the community.

Why this is needed:
Generics are a very new Go feature, and the implications of using them in a large codebase/project are unknown. Thus, it will be useful for contributors to have guidelines for how to use generics in the gateway-api codebase.

/good-first-issue

@keithmattix keithmattix added the kind/feature Categorizes issue or PR as related to a new feature. label Sep 14, 2022
@k8s-ci-robot
Copy link
Contributor

@keithmattix:
This request has been marked as suitable for new contributors.

Guidelines

Please ensure that the issue body includes answers to the following questions:

  • Why are we solving this issue?
  • To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points?
  • Does this issue have zero to low barrier of entry?
  • How can the assignee reach out to you for help?

For more details on the requirements of such an issue, please see here and ensure that they are met.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-good-first-issue command.

In response to this:

What would you like to be added:
With generics shipping in go1.18, the gateway-api project needs to have some kind of policy around when and how generics should be used. If upstream Kubernetes has a policy, we likely need to mirror it.

Why this is needed:
Generics are a very new Go feature, and the implications of using them in a large codebase/project are unknown. Thus, it will be useful for contributors to have guidelines for how to use generics in the gateway-api codebase.

/good-first-issue

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.

@k8s-ci-robot k8s-ci-robot added good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. labels Sep 14, 2022
@akankshakumari393
Copy link
Member

I would like to work on this issue. But would need guidance as well
/assign

@mikemorris
Copy link
Contributor

Refs https://github.com/kubernetes/community/blob/master/sig-architecture/generics.md for the upstream Kubernetes policy, and kubernetes/kubernetes#106846 as a specific attempt at introducing generics in a meaningful way.

FWIW I did previously introduce some trivial usage of generics in #1081

@akankshakumari393
Copy link
Member

We have a upstream Kubernetes policy in place for using generics, I think we should mirror it for single source of truth

@k8s-triage-robot
Copy link

The Kubernetes project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

  • After 90d of inactivity, lifecycle/stale is applied
  • After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
  • After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

  • Mark this PR as fresh with /remove-lifecycle stale
  • Close this PR with /close
  • Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Feb 8, 2023
@shaneutt shaneutt moved this to In Progress in Gateway API: GAMMA Initiative Mar 8, 2023
@shaneutt
Copy link
Member

Where are we at with this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. kind/feature Categorizes issue or PR as related to a new feature. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale.
Projects
Development

No branches or pull requests

6 participants