@@ -125,10 +125,18 @@ this are based on the Kubernetes process:
125125* Extensions can be granted on a per-GEP basis
126126 * The owners of the GEP have to ask and provide a timeline (measured in
127127 days) as to when they believe the GEP will be ready for merge.
128- * The request and approval for a GEP extension needs to be in public.
128+ * The request and approval for a GEP extension must be on the original GEP issue.
129+ * An extension can only be granted for a time period up to the distance from
130+ the deadline when the extension is requested. So, an extension of a week
131+ must be asked for at least a week out from a deadline, while an extension of
132+ day must be asked for at least a day out from the deadline. Extension requests
133+ not meeting this timing criteria will be denied.
129134* Extensions can only be granted with a majority agreement by maintainers
130- / release-managers
135+ / release-managers.
131136
132- For our purposes we use GitHub discussions as the public place for
133- requesting/approving extensions. Contributors should use an existing
134- discussion for the release when feasible, otherwise create a discussion.
137+ For our purposes we use GitHub issues, specifically the related GEP issue,
138+ as the public place for requesting/approving extensions.
139+
140+ This extension policy also affects reviews.
141+ If feedback is submitted sufficiently late that it is impossible to address within these guidelines,
142+ the feedback (not necessarily the GEP) may be deferred to a future release.
0 commit comments