Skip to content

Commit c824f92

Browse files
devigneddanbugs
devigned
and
danbugs
authored
create the hyperlight proposal process (#25)
Signed-off-by: David Justice <[email protected]> Co-authored-by: Dan Chiarlone <[email protected]>
1 parent f0e4574 commit c824f92

File tree

3 files changed

+240
-0
lines changed

3 files changed

+240
-0
lines changed

‎proposals/0000-hip-process/README.md

Lines changed: 38 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,38 @@
1+
# Hyperlight Improvement Process
2+
3+
<!-- toc -->
4+
- [Summary](#summary)
5+
- [Motivation](#motivation)
6+
- [Goals](#goals)
7+
- [Non-Goals](#non-goals)
8+
- [Proposal](#proposal)
9+
<!-- /toc -->
10+
11+
## Summary
12+
13+
Hyperlight Improvement Proposals, otherwise known as HIPs, are largely influenced by the Kubernetes
14+
Enhancement Proposal (KEP) process which provides a standardized development process for Hyperlight
15+
enhancements. You can read more about the
16+
[KEP process in 0000-kep-process here](https://github.com/kubernetes/enhancements/blob/master/keps/sig-architecture/0000-kep-process/README.md).
17+
18+
## Motivation
19+
20+
### Goals
21+
22+
1. Since Hyperlight is a smaller project than Kubernetes and has a smaller community of contributors, the
23+
needs are slightly different from that of the Kubernetes project. HIPs do not strive to meet the rigor
24+
of their inspiration in Kubernetes, but rather, to provide a means for communication of intent and a
25+
historical record for the motivations that drove the improvement.
26+
27+
### Non-goals
28+
29+
1. To have all changes require a HIP. Only significantly impacting work should be stated as a HIP, e.g.
30+
a large refactoring, significant feature enhancements, breaking APIs, etc.
31+
2. We will omit the use of KEP like metadata that is associated with KEPs.
32+
33+
## Proposal
34+
35+
We propose creating a standardized improvement proposal process for Hyperlight modeled after the Kubernetes
36+
Enhancement Proposal process.
37+
38+

‎proposals/NNNN-hip-template/README.md

Lines changed: 177 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,177 @@
1+
# HIP NNNN - SKIP NAME
2+
3+
<!-- toc -->
4+
- [Summary](#summary)
5+
- [Motivation](#motivation)
6+
- [Goals](#goals)
7+
- [Non-Goals](#non-goals)
8+
- [Proposal](#proposal)
9+
- [User Stories (Optional)](#user-stories-optional)
10+
- [Story 1](#story-1)
11+
- [Story 2](#story-2)
12+
- [Notes/Constraints/Caveats (Optional)](#notesconstraintscaveats-optional)
13+
- [Risks and Mitigations](#risks-and-mitigations)
14+
- [Design Details](#design-details)
15+
- [Test Plan](#test-plan)
16+
- [Unit tests](#unit-tests)
17+
- [Integration tests](#integration-tests)
18+
- [e2e tests](#e2e-tests)
19+
- [Implementation History](#implementation-history)
20+
- [Drawbacks](#drawbacks)
21+
- [Alternatives](#alternatives)
22+
<!-- /toc -->
23+
24+
## Summary
25+
26+
<!--
27+
This section is incredibly important for producing high-quality, user-focused
28+
documentation such as release notes or a development roadmap. It should be
29+
possible to collect this information before implementation begins, in order to
30+
avoid requiring implementors to split their attention between writing release
31+
notes and implementing the feature itself. HIP editors should help to ensure
32+
that the tone and content of the `Summary` section is useful for a wide audience.
33+
34+
A good summary is probably at least a paragraph in length.
35+
36+
Both in this section and below, follow the guidelines of the [documentation
37+
style guide]. In particular, wrap lines to a reasonable length, to make it
38+
easier for reviewers to cite specific portions, and to minimize diff churn on
39+
updates.
40+
41+
[documentation style guide]: https://github.com/kubernetes/community/blob/master/contributors/guide/style-guide.md
42+
-->
43+
44+
## Motivation
45+
46+
<!--
47+
This section is for explicitly listing the motivation, goals, and non-goals of
48+
this HIP. Describe why the change is important and the benefits to users. The
49+
motivation section can optionally provide links to [experience reports] to
50+
demonstrate the interest in a KEP within the wider Kubernetes community.
51+
52+
[experience reports]: https://github.com/golang/go/wiki/ExperienceReports
53+
-->
54+
55+
### Goals
56+
57+
<!--
58+
List the specific goals of the HIP. What is it trying to achieve? How will we
59+
know that this has succeeded?
60+
-->
61+
62+
### Non-Goals
63+
64+
<!--
65+
What is out of scope for this HIP? Listing non-goals helps to focus discussion
66+
and make progress.
67+
-->
68+
69+
## Proposal
70+
71+
<!--
72+
This is where we get down to the specifics of what the proposal actually is.
73+
This should have enough detail that reviewers can understand exactly what
74+
you're proposing, but should not include things like API designs or
75+
implementation. What is the desired outcome and how do we measure success?.
76+
The "Design Details" section below is for the real
77+
nitty-gritty.
78+
-->
79+
80+
### User Stories (Optional)
81+
82+
<!--
83+
Detail the things that people will be able to do if this HIP is implemented.
84+
Include as much detail as possible so that people can understand the "how" of
85+
the system. The goal here is to make this feel real for users without getting
86+
bogged down.
87+
-->
88+
89+
#### Story 1
90+
91+
#### Story 2
92+
93+
### Notes/Constraints/Caveats (Optional)
94+
95+
<!--
96+
What are the caveats to the proposal?
97+
What are some important details that didn't come across above?
98+
Go in to as much detail as necessary here.
99+
This might be a good place to talk about core concepts and how they relate.
100+
-->
101+
102+
### Risks and Mitigations
103+
104+
<!--
105+
What are the risks of this proposal, and how do we mitigate? Think broadly.
106+
For example, consider both security and how this will impact the larger ecosystem.
107+
108+
How will security be reviewed, and by whom?
109+
-->
110+
111+
## Design Details
112+
113+
<!--
114+
This section should contain enough information that the specifics of your
115+
change are understandable. This may include API specs (though not always
116+
required) or even code snippets. If there's any ambiguity about HOW your
117+
proposal will be implemented, this is the place to discuss them.
118+
-->
119+
120+
### Test Plan
121+
122+
<!--
123+
The goal is to ensure that we don't accept enhancements with inadequate testing.
124+
125+
All code is expected to have adequate tests (eventually with coverage
126+
expectations).
127+
-->
128+
129+
##### Unit tests
130+
131+
<!--
132+
In principle every added code should have complete unit test coverage, so providing
133+
the exact set of tests will not bring additional value.
134+
However, if complete unit test coverage is not possible, explain the reason of it
135+
together with explanation why this is acceptable.
136+
-->
137+
138+
##### Integration tests
139+
140+
<!--
141+
Integration tests allow control of the configuration parameters used to start the binaries under test.
142+
This is different from e2e tests which do not allow configuration of parameters.
143+
Doing this allows testing non-default options and multiple different and potentially conflicting command line options.
144+
-->
145+
146+
##### e2e tests
147+
148+
<!--
149+
We expect no non-infra related flakes in the last month as a GA graduation criteria.
150+
-->
151+
152+
## Implementation History
153+
154+
<!--
155+
Major milestones in the lifecycle of a HIP should be tracked in this section.
156+
Major milestones might include:
157+
- the `Summary` and `Motivation` sections being merged, signaling SIG acceptance
158+
- the `Proposal` section being merged, signaling agreement on a proposed design
159+
- the date implementation started
160+
- the first Hyperlight release where an initial version of the HIP was available
161+
- the version of Hyperlight where the HIP graduated to general availability
162+
- when the HIP was retired or superseded
163+
-->
164+
165+
## Drawbacks
166+
167+
<!--
168+
Why should this HIP _not_ be implemented?
169+
-->
170+
171+
## Alternatives
172+
173+
<!--
174+
What other approaches did you consider, and why did you rule them out? These do
175+
not need to be as detailed as the proposal, but should include enough
176+
information to express the idea and why it was not acceptable.
177+
-->

‎proposals/README.md

Lines changed: 25 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,25 @@
1+
# Hyperlight Improvement Proposals (HIPs)
2+
3+
Hyperlight Improvement Proposals, otherwise known as HIPs, are largely influenced by the Kubernetes
4+
Enhancement Proposal (KEP) process which provides a standardized development process for Hyperlight
5+
enhancements. You can read more about the
6+
[KEP process in 0000-kep-process here](https://github.com/kubernetes/enhancements/blob/master/keps/sig-architecture/0000-kep-process/README.md).
7+
8+
## Authoring a HIP
9+
When you have a new enhancement that is more than a relatively trivial enhancement or bug fix, the
10+
change should be first socialized as a HIP. To help authors to get started a HIP template is located in
11+
[NNNN-hip-template](./NNNN-hip-template/README.md).
12+
13+
1. Create a new directory under [the proposals directory](../proposals) in the form of `NNNN-hip-${hip_name}`
14+
where `NNNN` is the next HIP number available. For example, if HIP 0001 is currently the highest number HIP and
15+
your enhancement is titled "Make Me a Sandwich", then your HIP would be `0002-hip-make-me-a-sandwich`.
16+
2. Within your `NNNN-hip-${hip_name}` directory create a file named `README.md` containing a copy of the HIP
17+
template.
18+
3. Author the content of the template. Not all sections are necessary. Please consider filling out the
19+
summary, motivation, and proposal sections first to gather early feedback on the desirability of the
20+
enhancement through a draft pull request.
21+
4. After socializing the proposal and integrating early feedback, continue with the rest of the sections.
22+
5. Update the pull request with the rest of the sections and remove the draft status from the pull request.
23+
6. Address any feedback to the proposal and get it merged.
24+
7. Implement the enhancement.
25+

0 commit comments

Comments
 (0)