RFC: Figure out policy for module specific code owners

[mattklein123]

Once #2069 is complete, we will be in a better position to have module specific code owners for extensions. This is good, because the number of requests to add extensions to the main repo is growing. We need to figure out the right way to scale this. I have a bunch of thoughts on this which I will write up within the next couple of weeks but going to open this now in case anyone in the community would like to share their thoughts.

cc @envoyproxy/maintainers

[alyssawilk]

I like the idea of "you add it, you own it" as a start, but that obviously doesn't work well if that person wants to hand off ownership for [reasons] and there's folks using the code who are users but not contributors to Envoy. I don't have solid ideas of what to do there, so I look forward to hearing your thoughts :-)

[mattklein123]

@envoyproxy/maintainers and other interested parties: I drafted a short document on a proposed policy for how extensions will be added to the repository in the future. Please comment!
https://docs.google.com/document/d/1eDQQSxqx2khTXfa2vVm4vqkyRwXYkPzZCcbjxJ2_AvA/edit#

[alanconway]

I will shortly have an extension to contribute, your policy proposal seems reasonable.

dynamic loading #2053 would facilitate externally maintained and packaged extensions without having to build a modified envoy binary, which potentially reduces your burden even more.

You might want a naming scheme for external extensions, e.g.

• internal "envoy.filters.network.amqp_http"
• external "qpid.apache.org/filters.network.amqp_http"

[mattklein123]

@alanconway agreed on both accounts re: dynamic loading and naming.