Date
1 - 20 of 34
[VOTE] linkerd moving to incubation
alexis richardson
+1 binding
toggle quoted message
Show quoted text
After some thought. I believe linkerd has met the incubation criteria. That is not hard to see. I am concerned that linkerd needs more momentum to sustain high quality development both from the buoyant folks and from the community. I don't think that overlap with envoy is the primary concern here. My main worry is with the overall roadmap and plan - long term what problems linkerd needs to solve well and under what assumptions. I'm voting +1 because I believe William, Oliver and co understand this is an issue and will work on it as they continue with Conduit in parallel. Let's see how things go! On Wed, 4 Apr 2018, 00:36 Jonathan Boulle, <jon@...> wrote:
|
|||||
|
|||||
Jonathan Boulle <jon@...>
toggle quoted message
Show quoted text
|
|||||
|
|||||
Camille Fournier
+1 binding On Tue, Apr 3, 2018 at 5:00 PM, Benjamin Hindman <benh@...> wrote:
|
|||||
|
|||||
Benjamin Hindman
+1 binding On Tue, Apr 3, 2018 at 8:47 AM Ken Owens <kenchristineowens@...> wrote:
--
Benjamin Hindman Founder of Mesosphere and Co-Creator of Apache Mesos Follow us on Twitter: @mesosphere
|
|||||
|
|||||
Ken Owens
+1 Binding On Fri, Mar 23, 2018 at 11:56 AM, William Morgan <william@...> wrote:
|
|||||
|
|||||
William Morgan
On Wed, Mar 21, 2018 at 2:51 PM, Brian Grant via Lists.Cncf.Io <briangrant=google.com@...
Yes.
Great suggestion. With the current model we aimed for the simplest, most basic structure that still captured what we thought was important (some maintainers are experts in a subsystem; some maintainers are experts in the overall workings). But we'll almost definitely need to refine this over time. Thinking about this further, it would've been really useful to have a library of vetted / "good" governance models to read through when we were doing this. Perhaps this is something the CNCF could provide as a resource for projects?
This is also very much in my interest and I'd love any help, though I'm not sure what the CNCF would be able to do about this in practice. In Linkerd's case, at least, contributorship only really happened after there was significant adoption. |
|||||
|
|||||
Brian Grant
I assume the maintainers govern all linkerd repositories, since other repositories do not contain MAINTAINERS.md files. I see (super-)maintainers can be added via nomination and vote. It may be useful to develop a particular contribution bar for (super-)maintainers, such as number of commits or duration on the project or number of subsystems they have worked on, so contributors know roughly what to strive for and existing (super-)maintainers have guidelines for nominating new members of those groups. Given that the PR backlog doesn't seem to be growing, I assume that the current number of super-maintainers is sufficient to keep up with the current review/approval load. Something we (CNCF) need to think about that isn't specific to Linkerd is what activity level(s) we expect, since some projects are naturally larger and/or more active than others. Clearly we do care about contributor diversity, so that's something we should explore whether/how CNCF could help improve that in the future. Though there is more work to do, I believe that linkerd meets the bar for incubation. +1 binding On Tue, Mar 20, 2018 at 8:11 AM William Morgan <william@...> wrote:
|
|||||
|
|||||
William Morgan
Whoops, thanks for pointing that out. I count 3 PRs out of the last 18 or so that violated the governance rules about requiring a super-maintainer review, all minor. We're still adjusting to some of these changes... this will improve. -William On Tue, Mar 20, 2018 at 7:19 AM, Justin Cormack via Lists.Cncf.Io <justin.cormack=docker.com@...> wrote:
|
|||||
|
|||||
Justin Cormack
0 (non binding) The governance seems confused and I am not sure it technically meets the criteria of number of committers. The governance doc[1] states "All PRs must receive approval from at least one super maintainer before merge", so as there are only two super maintainers only two people are "someone who can accept contributions to some or all of the project". In practise this is ignored, and there are additional people with Github commit access, not listed as maintainers who are merging many of the PRs, often without super maintainer approval. I know the CNCF does not require full governance at this stage but the fact that the newly added governance seems to be ignored is a concern, as external contributors are being treated differently. On Thu, Mar 15, 2018 at 5:28 PM, Chris Aniszczyk <caniszczyk@...> wrote:
|
|||||
|
|||||
William Morgan
On Mon, Mar 19, 2018 at 8:17 PM, Brian Grant via Lists.Cncf.Io <briangrant=google.com@...> wrote:
Most that we're aware of run Linkerd per host. There are a couple companies that use it as a sidecar, and don't Linkerd's resource requirements heavyweight relative to the existing footprint of their services.
Absolutely. The JVM platform and the plugin model are huge deal for some very large companies. I'm happy to provide examples off list. |
|||||
|
|||||
William Morgan
Yes. I can't speak for the other community folks, but Buoyant is planning its Q2 Linkerd roadmap right now. Dark traffic, rate limiting, backup requests, configurable communication policy in namerd, and a couple other big features are all on the docket. -William On Mon, Mar 19, 2018 at 7:48 PM, Brian Grant <briangrant@...> wrote:
|
|||||
|
|||||
Robert Panzer
+1 (non-binding)
|
|||||
|
|||||
Brian Grant
At the moment, it looks like linkerd maybe still has more user mindshare, though envoy has more contributors. Linkerd doesn't have to run as a host-level proxy, though I don't know how many people deploy it as a sidecar in practice. Host-level proxies also can make sense in some scenarios. Maybe what you're getting at is what do we see as the driving use cases in the future for linkerd, relative to alternatives such as envoy and conduit? The only direct comparison I found in a quick search was in the envoy docs, and looks possibly out of date: I don't know how much of an issue it is for linkerd users, but, irrespective of features and resource profiles, I could imagine a language preference, for dev and ops teams familiar with Java/Scala, particularly if they are writing plugins. Since users will ask, it would be useful to provide some information they could use to choose one or the other. But I don't think that impacts whether linkerd currently meets the bar for incubation or not, and by our "no kingmaking" principle it seems premature for us to choose one now. On Thu, Mar 15, 2018 at 9:02 PM Justin Garrison <justinleegarrison@...> wrote:
|
|||||
|
|||||
Brian Grant
Hi, William. Are there any specific large areas of upcoming development in linkerd, which would provide an opportunity for onboarding new contributors? Most post-1.3.0 (reasonably) looks like fixes and minor improvements. https://github.com/linkerd/linkerd/graphs/contributors https://github.com/linkerd/linkerd/pulls?q=is%3Apr+is%3Aclosed On Thu, Mar 15, 2018 at 1:28 PM William Morgan <william@...> wrote:
|
|||||
|
|||||
cncf.io@...
+1 (non-binding)
|
|||||
|
|||||
Ben Hoyt
+1 (non-binding) |
|||||
|
|||||
Richard Hartmann
+1 non-binding
|
|||||
|
|||||
Nikolay Pshenichnyy
+1 (non-binding)
Linkerd is an excellent service mesh proxy! |
|||||
|
|||||
+1 (non-binding) On Thu, Mar 15, 2018 at 5:28 PM, Chris Aniszczyk <caniszczyk@...> wrote:
|
|||||
|
|||||
alexis richardson
thank-you for the detailed summary, George!
toggle quoted message
Show quoted text
On Fri, Mar 16, 2018 at 8:22 PM, Georgi Khomeriki <g.khomeriki@...> wrote:
+1 (non binding) |
|||||
|