toggle quoted message
Show quoted text
So Tara's point, and please correct me if I'm wrong, is that the project in the incubation phase is expected to have a growth plan
. The idea here is that there should be a consensus and transparency around what the project is seeking. I agree that that should be captured (and missing this is a failure on our part, because the project proposal requirement section
doesn't list it!) I think this is something we need to hear from Jithin, the product owner. I'd imagine it could be somewhere around more user adoption, more contributors, etc.
The next question from there is how the project is going to achieve those goals. I don't think it should be just "we can achieve those goals by coming to the CDF." I'd really love to see it go a step further. For example, if more contribution is a goal, then I think the growth plan could call out more open governance and decision making process. Or if the acceleration of the development is the goal, the growth plan could call out identifying and reusing common parts with other CDF projects.
I think calling out more active engagement with other CDF projects would be really exciting. My perception, though I could be wrong, is that there are a considerable overlap between what Screwdriver does and Spinnaker/Jenkins/Tekton/JenkinsX do. There gotta be libraries/subsystems/microserviecs that we can refactor out of those projects so that we don't keep reinventing wheel. I think Screwdriver could be a great driver because it has modest adoption and thus hopefully more amenable to compatibility breaking change.
On Tue, Aug 6, 2019 at 6:08 PM Kohsuke Kawaguchi <kk@...
I'm a little late to the party as I was on vacation. Looks like this topic needs more discussion before we call a vote.
I hear the point from Andy & Tara that, in my understanding, basically boils down to "how does this new project fit with all the other projects?" It's a perfectly legitimate question. I'm imagining that that question is coming from a natural desire of having a portfolio of projects that are complementary and non-overlapping. I certainly share the goal that we amass such projects, so that collectively we can tell a bigger story and make a bigger impact.
That said, in my past experience with open-source projects, it doesn't work very well trying to hand-pick a curated portfolio upfront. One reason is that a healthy competition and chaotic breeding ground is actually pretty crucial to sustain the ecosystem as a whole, aka creative destruction
. Another reason is that we cannot predict a winner. Only a market can.
I'm an old timer so I'll start with XML parsers at Apache. Originally IBM donated its code as Xerces, then Sun donated its code as Crimson. There was a period in which they were both actively maintained as separate projects. They had different pros and cons, such as footprint, modularity, etc. Then they decided to do a joint rewrite, which later became "Xerces 2," which learnt from both Xerces 1 & Crimson. I think overall this was great. Because Xerces 1 and Crimson were both under Apache, they knew each other. Features, ideas, and code cross-pollinated. I'm pretty sure that helped building a common sentiment of "why are we duplicating this work?" After all, every time something changes in XML, they had to do very similar work twice. If Crimson was not allowed into Apache because it was overlapping with Xerces, then Sun probably would have taken that project somewhere else, and this kind of collaboration wouldn't have happened.
Apache data projects are another great examples. There are so many projects with considerable overlap
. That's collective eyeballs of developers at work to kill any blind spots. If there is a master mind committee of Apache data projects that decide who gets in, I don't think the ecosystem would have been as robust as it is. At smaller scale, I see the same thing plays out in the Jenkins plugins. There have been many times where similar, overlapping plugins were produced. We choose quite consciously not to reject duplicates, and instead we chose to encourage those people to meet, talk, and work together.
I'm a firm believer that the CDF should adopt a similar mindset. We should welcome projects that might disrupt some of our existing projects. And to reiterate the first point, I'm also a firm believer that we should actively recruit projects that are complementary and non-overlapping. Those two goals aren't mutually exclusive.
Tara has the other point around the growth goal. I'm going to look at that next and respond separately.
On Wed, Jul 31, 2019 at 6:29 PM Tara Hernandez via Lists.Cd.Foundation <tarahernandez=google.com@...> wrote:
(as a 'defer' not a 'deny')
To Andy's point, I also feel like we need better details and transparency around the goals of the existing projects so that we can quantify how any new projects fit into that picture. Additionally, I'm not sure Screwdriver fits the current descriptions for new projects as defined in the project lifecycle doc around growth goals, at least as currently written. I'd like to see us get clarify on both of those points before moving forward.
All that said, Screwdriver is a very neat tool with what appears to be a strong core team that is still very much worth of consideration, so it behooves us to figure this out sooner rather than later. It may well be the perfect project to help us work out the kinks, if you will...
On Tue, Jul 30, 2019 at 9:51 PM Avi Kessner <akessner@...
+1 non binding.
I saw the screwdriver presentation and it looked really impressive. After the fundamentals are agreed upon I think it could be a great asset.
On Tue, Jul 30, 2019, 14:37 Andy Glover via Lists.Cd.Foundation <aglover=netflix.com@...> wrote:
I am a -1. We (the CDF TOC) haven't (yet) formalized an interoperability plan/strategy for the existing member projects. I think we should clarify how all these projects fit together for the benefit of end users before accepting new projects. I think Screwdriver is interesting and we could all learn from that community, but I'd love to defer adding it (or other projects) until we have a clear story for the founding projects.
On Tue, Jul 30, 2019 at 12:07 PM Dan Lorenc via Lists.Cd.Foundation <dlorenc=google.com@...> wrote:
project has been formally proposed for inclusion in the CDF. The proposal information can be found here: https://github.com/cdfoundation/toc/pull/22
And the team's presentation to the TOC can be found here
Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!
Director of Delivery Engineering
Engineering Manager Google Cloud