governance: issue resolution / voting and adding projects#2038
governance: issue resolution / voting and adding projects#2038mattklein123 merged 3 commits intomasterfrom
Conversation
Fixes #1670 Signed-off-by: Matt Klein <mklein@lyft.com>
|
@htuch I think this is roughly what we discussed a long time ago. Putting it out there officially. @caniszczyk LMK if this looks OK. |
htuch
left a comment
There was a problem hiding this comment.
+1 on the basic approach outlined, thanks.
GOVERNANCE.md
Outdated
| New projects will be added to the envoyproxy organization via GitHub issue discussion in one of the | ||
| existing projects in the organization. Once sufficient discussion has taken place (~3-5 business | ||
| days but depending on the volume of conversation), the maintainers will decide whether the new | ||
| project should be added (see the section above on voting if the maintainers cannot easily decide). |
There was a problem hiding this comment.
Are maintainers on the Envoy project maintainers with same seniority across all projects in envoyproxy? I think (?) that is what's being done today, but for example, I'm providing little value on go-control-plane and it might make sense as we scale to have project specific maintainers who can provide leadership in the areas of their focus and expertise.
There was a problem hiding this comment.
Agreed, let me try to clarify this.
| maintainer access. | ||
| * "Standard" maintainer access can be upgraded to "senior" maintainer access after another 1-2 | ||
| months of work and another conference of the existing senior maintainers. | ||
|
|
There was a problem hiding this comment.
As we scale, I think we should aim to have a more even load balancing across maintainers of routine reviews, mailing list and Slack activity. We've all agreed this is desirable. I'm not sure if I have anything actionable for this review, so just consider this comment a friendly ping while we're thinking about governance and organizational structure.
The other thing to consider is what scenarios lead to someone no longer being a maintainer. I have no opinions on this other than to ask what are the best practices? Internally, folks gets the moral equivalent of maintainer when they are actively contributing and reviewing, but if they are no longer active and interested, it's removed.
There was a problem hiding this comment.
As we scale, I think we should aim to have a more even load balancing across maintainers of routine reviews, mailing list and Slack activity. We've all agreed this is desirable. I'm not sure if I have anything actionable for this review, so just consider this comment a friendly ping while we're thinking about governance and organizational structure.
Yes I agree. I'm not really sure how to codify this. It's hard to hold people to doing this unless we actually start an "on-call" which is something that we could consider.
The other thing to consider is what scenarios lead to someone no longer being a maintainer. I have no opinions on this other than to ask what are the best practices? Internally, folks gets the moral equivalent of maintainer when they are actively contributing and reviewing, but if they are no longer active and interested, it's removed.
In spirit, this is what most projects do, though again it will be hard to have a rule. For example I think FreeBSD has some rule where if a maintainer does not commit anything for 1 year they get removed. That's a very different type of project and that seems pretty long. I will try to come up with some basic text here.
|
@htuch updated @envoyproxy/maintainers please review |
|
|
||
| # Adding new projects to the envoyproxy GitHub organization | ||
|
|
||
| New projects will be added to the envoyproxy organization via GitHub issue discussion in one of the |
There was a problem hiding this comment.
I can't think of a concrete example, but what would happen if someone wants to add a project that does not logically fit as an issue in any of the existing projects. Would it be worth it to have a repo for RFCs of this type?
There was a problem hiding this comment.
Yeah I think that's a good idea, though I think they could email envoy-dev@, etc. so maybe let's see if this becomes a real sisue?
* Improve performance by removing MD5 for check cache keys (envoyproxy#2002) * Improve performance by removing MD5 for check cache keys Signed-off-by: Wayne Zhang <qiwzhang@google.com> * not to allocate memory from stack Signed-off-by: Wayne Zhang <qiwzhang@google.com> * Make debug string readable Signed-off-by: Wayne Zhang <qiwzhang@google.com> * alts: remove ALTS (envoyproxy#2003) Signed-off-by: Lizan Zhou <lizan@tetrate.io> * Use std::hash for check cache. (envoyproxy#2009) Signed-off-by: Wayne Zhang <qiwzhang@google.com> * Remove tests to compare signature values (envoyproxy#2015) Signed-off-by: Wayne Zhang <qiwzhang@google.com> * update sample envoy config to latest version (envoyproxy#2016) * Add a new TCP cluster rewrite filter (envoyproxy#2017) * Add a new TCP cluster rewrite filter This commit adds a new TCP cluster rewrite filter which allows users to rewrite TCP cluster names obtained via TLS SNI by matching via regex configuration. Signed-off-by: Venil Noronha <veniln@vmware.com> * Make TCP cluster rewrite stackable on SNI filter This commit updates the TCP Cluster Rewrite filter to be stackable on the SNI Cluster filter. Signed-off-by: Venil Noronha <veniln@vmware.com> * Update TCP Cluster Rewrite filter name (envoyproxy#2019) This commit updates the TCP Cluster Rewrite filter name to envoy.filters.network.tcp_cluster_rewrite. Signed-off-by: Venil Noronha <veniln@vmware.com> * Enable TCP Cluster Rewrite filter registration (envoyproxy#2021) This commit enables the static registration of the TCP Cluster Rewrite filter by updating the build configuration. Signed-off-by: Venil Noronha <veniln@vmware.com> * Update Envoy SHA to 4ef8562 (envoyproxy#2023) Envoy /server_info API was inconsistent intermittently causing errors on a Proxy update on Istio. This update will bring in the API fix to Istio. Signed-off-by: Venil Noronha <veniln@vmware.com> * add proxy postsubmit periodic (envoyproxy#2025) * Update Envoy SHA to c41fa71 (envoyproxy#2029) * Update Envoy SHA Signed-off-by: JimmyCYJ <jimmychen.0102@gmail.com> * Fix format. Signed-off-by: JimmyCYJ <jimmychen.0102@gmail.com> * bazel: Allow to distdir all dependencies (envoyproxy#2034) To use --distdir option of Bazel (which allows to use previously fetched tarballs instead of downloading dependencies during build), all dependencies should use http instead of git and need to have sha256 sums specified. Signed-off-by: Michal Rostecki <mrostecki@suse.de> * bazel: Remove BoringSSL repository (envoyproxy#2035) Pull request envoyproxy#2002 removed signature calculation which was using BoringSSL as a dependency. BoringSSL is not needed anymore. Signed-off-by: Michal Rostecki <mrostecki@suse.de> * Update Envoy SHA to fcc68f1 (envoyproxy#2037) * Update Envoy SHA to fcc68f1 Signed-off-by: JimmyCYJ <jimmychen.0102@gmail.com> * Update SHA256 Signed-off-by: JimmyCYJ <jimmychen.0102@gmail.com>
Signed-off-by: Alyssa Wilk <alyssar@chromium.org> Signed-off-by: JP Simard <jp@jpsim.com>
Signed-off-by: Alyssa Wilk <alyssar@chromium.org> Signed-off-by: JP Simard <jp@jpsim.com>
Fixes #1670
Signed-off-by: Matt Klein mklein@lyft.com