Add Release Requirements Policy #40
Conversation
t8m
force-pushed
the
release-requirements
branch
from
bfa9b4b
to
e71fd19
Compare
t8m
force-pushed
the
release-requirements
branch
from
e71fd19
to
053abc2
Compare
|
Fixes #22 |
|
@mattcaswell fixup pushed addressing your comments. |
|
Updated to deal with some/most? of the comments from the OTC discussion. Please re-review. |
|
Based on the OTC discussion we had yesterday, I've added a separate Patch releases section. I've also simplified and removed some duplications and moved some things to the Triage process section. |
|
@openssl/otc please re-review as I plan to start a vote soon. |
| regression or security fixes should be merged during the freeze. | ||
| - For 2 days before the release there should be no changes to ensure the daily | ||
| CI builds run on the development tree tip. | ||
| - Embargoed security fixes are excepted from the rule above as they cannot |
There was a problem hiding this comment.
Are there more steps associated with security patches (CVE's and notifications)?
There was a problem hiding this comment.
IMO they should not belong here as they would confuse things. If we have any security release process policy, it should be there.
There was a problem hiding this comment.
it still sounds like Release requirements to me..
There was a problem hiding this comment.
In order to do the security release these are requirements - It could be a link to another document...
There was a problem hiding this comment.
We can/should do that later.
t8m
added
the
ready to vote
|
Starting the vote for Add Release Requirements Policy at commit 1845646 |
|
Vote: [+1] |
6 similar comments
|
Vote: [+1] |
|
Vote: [+1] |
|
Vote: [+1] |
|
Vote: [+1] |
|
Vote: [+1] |
|
Vote: [+1] |
| - The OTC should explicitly approve that the source is ready for a release with | ||
| a vote. | ||
|
|
||
| Patch Releases |
There was a problem hiding this comment.
It can be noted that we have also call these "release updates", see policies/stable-release-updates.md
There was a problem hiding this comment.
(if we want to change the nomenclature to "patch releases", we should probably do that across the board... but still leave a note somewhere saying what we used to call it, to connect the dots. Frankly, I'd welcome such a change, since "patch release" is a broadly used term)
|
Vote: [+1] |
1 similar comment
|
Vote: [+1] |
| bug is a regression or not. | ||
|
|
||
| In general regressions should be fixed as soon as possible, optimally before | ||
| the next release from the development tree is done. However sometimes that |
There was a problem hiding this comment.
It's unclear to me what you mean with development tree. I suggest you make it: "before the next release is done"
There was a problem hiding this comment.
Too late. The vote has started.
There was a problem hiding this comment.
You can always create an other PR to fix that.
| an OTC member according to what is the type (feature, bug, documentation, | ||
| refactoring, ...) of the issue or pull request. When the triage happens for an | ||
| issue or pull request that is a bug/bug fix, it must be assessed whether the | ||
| bug is a regression or not. |
There was a problem hiding this comment.
How do we mark something as regression? Do we just assign it milestones?
There was a problem hiding this comment.
There is now a label: severity: regression.
There was a problem hiding this comment.
I think this policy should be more clear about such labels.
|
Voting +1 |
|
Closing the vote. |
t8m
added
accepted
This adds the policy that covers general requirements that must be met before we create a release (alpha/beta/stable).
It also describes the issue and pull request triage process in short.