Topics

Thoughts from OSLS


Kohsuke Kawaguchi
 

I'm back to work from the hectic week that is OSLS. As everyone said it before, the launch went really well. Here are some thoughts that I'm starting to form that's relevant to what TOC might want to take on.
  • Several people who are behind some of the "CD" projects came up to me and showed their interest to bring their projects under the CDF. All of them are overlapping to some degree with some of the 4 projects that we already have. That by itself isn't a bad thing, but it did make me wonder how we'd approach them. I feel like the industry and vendors are watching what color this foundation will take in the next few months, and if we build a super market with 4 different kind of apples without any oranges, I don't know if that's the message we want to send.

  • But another way to look at this is that the reasons those 4 different apples exist (in various different stages of maturity) is that devops teams needed to scratch their itches, and I'd think a part of the reason is that they weren't aware, or didn't feel comfortable joining other projects. I think we can solve those problems here, and that might encourage more collaboration and result in more consolidation, which I think is a better outcome.

  • From there, my mind went to "how do we solve that?" There are a lot of things we can do for sure, and some of those are already mentioned by people when we met. For example, putting people behind those projects together and sharing what problems they are trying to solve to each other would be a great step. Another one I thought is to set a bar or provide help to participating projects about transparency to the governance and/or the vision, which help other organized potential contributors to see if it's aligned with what they need, or they need to build something else. That kind of visibility feels like a sign of maturity anyway.

  • Relevant to above visibility/transparency is that people wanted understand where the collaboration with Tekton and Jenkins are happening and what that means.

  • From the "4 different kind of apples without any oranges" thought, another place my head went is that it'd be great to recruit projects more proactively (or at least build relations with.) I think that requires drawing a mental map of the super market, that is the CD space.

  • Finally, completely tangentially, I always thought there are lots of rooms for more API/interop focused small projects. I'm a big fan of Grafeas. Another example is the machine readable input/output to test frameworks --- there's the test report format that JUnit started but now used everywhere from nosetest to rspec, and that could really use a name and a schema. Then I'd love to see a mechanism that allows CI/CD tool to specify a subset of tests to run and its order, for more frictionless parallelism and efficiency. It's all fairly trivial things but it takes putting the right group of people in the room to make happen!!

As you can see, random unorganized thoughts here. Love to hear other people's own thoughts.

--
Kohsuke Kawaguchi


Dan Lorenc
 

Thanks for sending this! Some thoughts inline, and I look forward to discussing more in person.

On Fri, Mar 15, 2019 at 12:51 PM Kohsuke Kawaguchi <kk@...> wrote:
I'm back to work from the hectic week that is OSLS. As everyone said it before, the launch went really well. Here are some thoughts that I'm starting to form that's relevant to what TOC might want to take on.
  • Several people who are behind some of the "CD" projects came up to me and showed their interest to bring their projects under the CDF. All of them are overlapping to some degree with some of the 4 projects that we already have. That by itself isn't a bad thing, but it did make me wonder how we'd approach them. I feel like the industry and vendors are watching what color this foundation will take in the next few months, and if we build a super market with 4 different kind of apples without any oranges, I don't know if that's the message we want to send.
This came up with me as well. I think we should try to understand the motivations these companies have for placing these projects in a foundation and make sure we have places/levels in place for the broad range of projects/motivations. For example, some companies seem to be motivated by:
  • getting a broader contributor base
  • solving a large industry problem that can't be done in isolation
  • marketing, other project support
  • credibility of being in a foundation
We should prioritize establishing a set of areas where the appropriate type of collaboration can take place for each project. CNCF has sandbox, incubating, graduation, etc. to help. Other foundations have other types of "levels".

A sign of a healthy ecosystem would be projects both inside and outside the foundation interoperating and building on each other. We should also work to dispel any notions that projects must be in the CDF to interoperate with the CDF projects. A CDF landscape would be a big help here. I think Chris said these are pretty easy to setup.

  • But another way to look at this is that the reasons those 4 different apples exist (in various different stages of maturity) is that devops teams needed to scratch their itches, and I'd think a part of the reason is that they weren't aware, or didn't feel comfortable joining other projects. I think we can solve those problems here, and that might encourage more collaboration and result in more consolidation, which I think is a better outcome.

Definitely, vendor-neutral owned projects can be much more welcoming to others. 
  • From there, my mind went to "how do we solve that?" There are a lot of things we can do for sure, and some of those are already mentioned by people when we met. For example, putting people behind those projects together and sharing what problems they are trying to solve to each other would be a great step. Another one I thought is to set a bar or provide help to participating projects about transparency to the governance and/or the vision, which help other organized potential contributors to see if it's aligned with what they need, or they need to build something else. That kind of visibility feels like a sign of maturity anyway.

  • Relevant to above visibility/transparency is that people wanted understand where the collaboration with Tekton and Jenkins are happening and what that means.
 Right! I look forward to having these conversations in central, public discussions hosted by the CDF going forward. They've mostly been informal adhoc meetings so far.
  •  


  • From the "4 different kind of apples without any oranges" thought, another place my head went is that it'd be great to recruit projects more proactively (or at least build relations with.) I think that requires drawing a mental map of the super market, that is the CD space.

  • Finally, completely tangentially, I always thought there are lots of rooms for more API/interop focused small projects. I'm a big fan of Grafeas. Another example is the machine readable input/output to test frameworks --- there's the test report format that JUnit started but now used everywhere from nosetest to rspec, and that could really use a name and a schema.
A few other CDF members expressed interest in Grafeas as well. I'll follow up on this in the next couple of weeks. I think there's definitely a need for a CD-focused, secure metadata standard for interop. 
  • Then I'd love to see a mechanism that allows CI/CD tool to specify a subset of tests to run and its order, for more frictionless parallelism and efficiency. It's all fairly trivial things but it takes putting the right group of people in the room to make happen!!

As you can see, random unorganized thoughts here. Love to hear other people's own thoughts.

--
Kohsuke Kawaguchi


Chris Aniszczyk
 

I'm happy to see this discussion going on and my advice would be to focus on two things:

1) establish a set of principles/values that the CDF TOC can agree on as clarity helps with consensus building, see this as an example: https://github.com/cncf/toc/blob/master/PRINCIPLES.md or https://github.com/cncf/foundation/blob/master/charter.md#3-values

There are good ideas to pull from CNCF and other communities out there, with an opportunity to put your own spin on it.

2) establish a project acceptance/lifecycle process:


I'd start there before worrying about landscapes or new projects, establishing a set of values and process the TOC and the community agrees on is critical. While this discussion is happening, the rest of the TOC will be filled out by the GB over the coming couple months (after the GB meets for the first time next month).

Those are my two cents :)

On Fri, Mar 15, 2019 at 11:01 AM Dan Lorenc via Lists.Cd.Foundation <dlorenc=google.com@...> wrote:
Thanks for sending this! Some thoughts inline, and I look forward to discussing more in person.

On Fri, Mar 15, 2019 at 12:51 PM Kohsuke Kawaguchi <kk@...> wrote:
I'm back to work from the hectic week that is OSLS. As everyone said it before, the launch went really well. Here are some thoughts that I'm starting to form that's relevant to what TOC might want to take on.
  • Several people who are behind some of the "CD" projects came up to me and showed their interest to bring their projects under the CDF. All of them are overlapping to some degree with some of the 4 projects that we already have. That by itself isn't a bad thing, but it did make me wonder how we'd approach them. I feel like the industry and vendors are watching what color this foundation will take in the next few months, and if we build a super market with 4 different kind of apples without any oranges, I don't know if that's the message we want to send.
This came up with me as well. I think we should try to understand the motivations these companies have for placing these projects in a foundation and make sure we have places/levels in place for the broad range of projects/motivations. For example, some companies seem to be motivated by:
  • getting a broader contributor base
  • solving a large industry problem that can't be done in isolation
  • marketing, other project support
  • credibility of being in a foundation
We should prioritize establishing a set of areas where the appropriate type of collaboration can take place for each project. CNCF has sandbox, incubating, graduation, etc. to help. Other foundations have other types of "levels".

A sign of a healthy ecosystem would be projects both inside and outside the foundation interoperating and building on each other. We should also work to dispel any notions that projects must be in the CDF to interoperate with the CDF projects. A CDF landscape would be a big help here. I think Chris said these are pretty easy to setup.

  • But another way to look at this is that the reasons those 4 different apples exist (in various different stages of maturity) is that devops teams needed to scratch their itches, and I'd think a part of the reason is that they weren't aware, or didn't feel comfortable joining other projects. I think we can solve those problems here, and that might encourage more collaboration and result in more consolidation, which I think is a better outcome.

Definitely, vendor-neutral owned projects can be much more welcoming to others. 
  • From there, my mind went to "how do we solve that?" There are a lot of things we can do for sure, and some of those are already mentioned by people when we met. For example, putting people behind those projects together and sharing what problems they are trying to solve to each other would be a great step. Another one I thought is to set a bar or provide help to participating projects about transparency to the governance and/or the vision, which help other organized potential contributors to see if it's aligned with what they need, or they need to build something else. That kind of visibility feels like a sign of maturity anyway.

  • Relevant to above visibility/transparency is that people wanted understand where the collaboration with Tekton and Jenkins are happening and what that means.
 Right! I look forward to having these conversations in central, public discussions hosted by the CDF going forward. They've mostly been informal adhoc meetings so far.
  •  


  • From the "4 different kind of apples without any oranges" thought, another place my head went is that it'd be great to recruit projects more proactively (or at least build relations with.) I think that requires drawing a mental map of the super market, that is the CD space.

  • Finally, completely tangentially, I always thought there are lots of rooms for more API/interop focused small projects. I'm a big fan of Grafeas. Another example is the machine readable input/output to test frameworks --- there's the test report format that JUnit started but now used everywhere from nosetest to rspec, and that could really use a name and a schema.
A few other CDF members expressed interest in Grafeas as well. I'll follow up on this in the next couple of weeks. I think there's definitely a need for a CD-focused, secure metadata standard for interop. 
  • Then I'd love to see a mechanism that allows CI/CD tool to specify a subset of tests to run and its order, for more frictionless parallelism and efficiency. It's all fairly trivial things but it takes putting the right group of people in the room to make happen!!

As you can see, random unorganized thoughts here. Love to hear other people's own thoughts.

--
Kohsuke Kawaguchi



--
Chris Aniszczyk (@cra) | +1-512-961-6719


Dan Lorenc
 

Thanks Chris! I threw some initial ideas on principles/values, etc. down here. I started with some of the format from the CNCF documents.


On Fri, Mar 15, 2019 at 4:41 PM Chris Aniszczyk <caniszczyk@...> wrote:
I'm happy to see this discussion going on and my advice would be to focus on two things:

1) establish a set of principles/values that the CDF TOC can agree on as clarity helps with consensus building, see this as an example: https://github.com/cncf/toc/blob/master/PRINCIPLES.md or https://github.com/cncf/foundation/blob/master/charter.md#3-values

There are good ideas to pull from CNCF and other communities out there, with an opportunity to put your own spin on it.

2) establish a project acceptance/lifecycle process:


I'd start there before worrying about landscapes or new projects, establishing a set of values and process the TOC and the community agrees on is critical. While this discussion is happening, the rest of the TOC will be filled out by the GB over the coming couple months (after the GB meets for the first time next month).

Those are my two cents :)

On Fri, Mar 15, 2019 at 11:01 AM Dan Lorenc via Lists.Cd.Foundation <dlorenc=google.com@...> wrote:
Thanks for sending this! Some thoughts inline, and I look forward to discussing more in person.

On Fri, Mar 15, 2019 at 12:51 PM Kohsuke Kawaguchi <kk@...> wrote:
I'm back to work from the hectic week that is OSLS. As everyone said it before, the launch went really well. Here are some thoughts that I'm starting to form that's relevant to what TOC might want to take on.
  • Several people who are behind some of the "CD" projects came up to me and showed their interest to bring their projects under the CDF. All of them are overlapping to some degree with some of the 4 projects that we already have. That by itself isn't a bad thing, but it did make me wonder how we'd approach them. I feel like the industry and vendors are watching what color this foundation will take in the next few months, and if we build a super market with 4 different kind of apples without any oranges, I don't know if that's the message we want to send.
This came up with me as well. I think we should try to understand the motivations these companies have for placing these projects in a foundation and make sure we have places/levels in place for the broad range of projects/motivations. For example, some companies seem to be motivated by:
  • getting a broader contributor base
  • solving a large industry problem that can't be done in isolation
  • marketing, other project support
  • credibility of being in a foundation
We should prioritize establishing a set of areas where the appropriate type of collaboration can take place for each project. CNCF has sandbox, incubating, graduation, etc. to help. Other foundations have other types of "levels".

A sign of a healthy ecosystem would be projects both inside and outside the foundation interoperating and building on each other. We should also work to dispel any notions that projects must be in the CDF to interoperate with the CDF projects. A CDF landscape would be a big help here. I think Chris said these are pretty easy to setup.

  • But another way to look at this is that the reasons those 4 different apples exist (in various different stages of maturity) is that devops teams needed to scratch their itches, and I'd think a part of the reason is that they weren't aware, or didn't feel comfortable joining other projects. I think we can solve those problems here, and that might encourage more collaboration and result in more consolidation, which I think is a better outcome.

Definitely, vendor-neutral owned projects can be much more welcoming to others. 
  • From there, my mind went to "how do we solve that?" There are a lot of things we can do for sure, and some of those are already mentioned by people when we met. For example, putting people behind those projects together and sharing what problems they are trying to solve to each other would be a great step. Another one I thought is to set a bar or provide help to participating projects about transparency to the governance and/or the vision, which help other organized potential contributors to see if it's aligned with what they need, or they need to build something else. That kind of visibility feels like a sign of maturity anyway.

  • Relevant to above visibility/transparency is that people wanted understand where the collaboration with Tekton and Jenkins are happening and what that means.
 Right! I look forward to having these conversations in central, public discussions hosted by the CDF going forward. They've mostly been informal adhoc meetings so far.
  •  


  • From the "4 different kind of apples without any oranges" thought, another place my head went is that it'd be great to recruit projects more proactively (or at least build relations with.) I think that requires drawing a mental map of the super market, that is the CD space.

  • Finally, completely tangentially, I always thought there are lots of rooms for more API/interop focused small projects. I'm a big fan of Grafeas. Another example is the machine readable input/output to test frameworks --- there's the test report format that JUnit started but now used everywhere from nosetest to rspec, and that could really use a name and a schema.
A few other CDF members expressed interest in Grafeas as well. I'll follow up on this in the next couple of weeks. I think there's definitely a need for a CD-focused, secure metadata standard for interop. 
  • Then I'd love to see a mechanism that allows CI/CD tool to specify a subset of tests to run and its order, for more frictionless parallelism and efficiency. It's all fairly trivial things but it takes putting the right group of people in the room to make happen!!

As you can see, random unorganized thoughts here. Love to hear other people's own thoughts.

--
Kohsuke Kawaguchi



--
Chris Aniszczyk (@cra) | +1-512-961-6719


Andy Glover
 

This is great, thanks for putting this together, Dan! 

-Andy


On Thu, Mar 21, 2019 at 7:30 AM Dan Lorenc via Lists.Cd.Foundation <dlorenc=google.com@...> wrote:
Thanks Chris! I threw some initial ideas on principles/values, etc. down here. I started with some of the format from the CNCF documents.

On Fri, Mar 15, 2019 at 4:41 PM Chris Aniszczyk <caniszczyk@...> wrote:
I'm happy to see this discussion going on and my advice would be to focus on two things:

1) establish a set of principles/values that the CDF TOC can agree on as clarity helps with consensus building, see this as an example: https://github.com/cncf/toc/blob/master/PRINCIPLES.md or https://github.com/cncf/foundation/blob/master/charter.md#3-values

There are good ideas to pull from CNCF and other communities out there, with an opportunity to put your own spin on it.

2) establish a project acceptance/lifecycle process:


I'd start there before worrying about landscapes or new projects, establishing a set of values and process the TOC and the community agrees on is critical. While this discussion is happening, the rest of the TOC will be filled out by the GB over the coming couple months (after the GB meets for the first time next month).

Those are my two cents :)

On Fri, Mar 15, 2019 at 11:01 AM Dan Lorenc via Lists.Cd.Foundation <dlorenc=google.com@...> wrote:
Thanks for sending this! Some thoughts inline, and I look forward to discussing more in person.

On Fri, Mar 15, 2019 at 12:51 PM Kohsuke Kawaguchi <kk@...> wrote:
I'm back to work from the hectic week that is OSLS. As everyone said it before, the launch went really well. Here are some thoughts that I'm starting to form that's relevant to what TOC might want to take on.
  • Several people who are behind some of the "CD" projects came up to me and showed their interest to bring their projects under the CDF. All of them are overlapping to some degree with some of the 4 projects that we already have. That by itself isn't a bad thing, but it did make me wonder how we'd approach them. I feel like the industry and vendors are watching what color this foundation will take in the next few months, and if we build a super market with 4 different kind of apples without any oranges, I don't know if that's the message we want to send.
This came up with me as well. I think we should try to understand the motivations these companies have for placing these projects in a foundation and make sure we have places/levels in place for the broad range of projects/motivations. For example, some companies seem to be motivated by:
  • getting a broader contributor base
  • solving a large industry problem that can't be done in isolation
  • marketing, other project support
  • credibility of being in a foundation
We should prioritize establishing a set of areas where the appropriate type of collaboration can take place for each project. CNCF has sandbox, incubating, graduation, etc. to help. Other foundations have other types of "levels".

A sign of a healthy ecosystem would be projects both inside and outside the foundation interoperating and building on each other. We should also work to dispel any notions that projects must be in the CDF to interoperate with the CDF projects. A CDF landscape would be a big help here. I think Chris said these are pretty easy to setup.

  • But another way to look at this is that the reasons those 4 different apples exist (in various different stages of maturity) is that devops teams needed to scratch their itches, and I'd think a part of the reason is that they weren't aware, or didn't feel comfortable joining other projects. I think we can solve those problems here, and that might encourage more collaboration and result in more consolidation, which I think is a better outcome.

Definitely, vendor-neutral owned projects can be much more welcoming to others. 
  • From there, my mind went to "how do we solve that?" There are a lot of things we can do for sure, and some of those are already mentioned by people when we met. For example, putting people behind those projects together and sharing what problems they are trying to solve to each other would be a great step. Another one I thought is to set a bar or provide help to participating projects about transparency to the governance and/or the vision, which help other organized potential contributors to see if it's aligned with what they need, or they need to build something else. That kind of visibility feels like a sign of maturity anyway.

  • Relevant to above visibility/transparency is that people wanted understand where the collaboration with Tekton and Jenkins are happening and what that means.
 Right! I look forward to having these conversations in central, public discussions hosted by the CDF going forward. They've mostly been informal adhoc meetings so far.
  •  


  • From the "4 different kind of apples without any oranges" thought, another place my head went is that it'd be great to recruit projects more proactively (or at least build relations with.) I think that requires drawing a mental map of the super market, that is the CD space.

  • Finally, completely tangentially, I always thought there are lots of rooms for more API/interop focused small projects. I'm a big fan of Grafeas. Another example is the machine readable input/output to test frameworks --- there's the test report format that JUnit started but now used everywhere from nosetest to rspec, and that could really use a name and a schema.
A few other CDF members expressed interest in Grafeas as well. I'll follow up on this in the next couple of weeks. I think there's definitely a need for a CD-focused, secure metadata standard for interop. 
  • Then I'd love to see a mechanism that allows CI/CD tool to specify a subset of tests to run and its order, for more frictionless parallelism and efficiency. It's all fairly trivial things but it takes putting the right group of people in the room to make happen!!

As you can see, random unorganized thoughts here. Love to hear other people's own thoughts.

--
Kohsuke Kawaguchi



--
Chris Aniszczyk (@cra) | +1-512-961-6719



--
Andrew Glover
Director of Delivery Engineering
Netflix, Inc.


Kohsuke Kawaguchi
 

Yes, this is great! I've made one pass. I gotta leave the keyboard now, but I'll come back to this later for more.

On Thu, Mar 21, 2019 at 7:38 AM Andy Glover via Lists.Cd.Foundation <aglover=netflix.com@...> wrote:
This is great, thanks for putting this together, Dan! 

-Andy


On Thu, Mar 21, 2019 at 7:30 AM Dan Lorenc via Lists.Cd.Foundation <dlorenc=google.com@...> wrote:
Thanks Chris! I threw some initial ideas on principles/values, etc. down here. I started with some of the format from the CNCF documents.

On Fri, Mar 15, 2019 at 4:41 PM Chris Aniszczyk <caniszczyk@...> wrote:
I'm happy to see this discussion going on and my advice would be to focus on two things:

1) establish a set of principles/values that the CDF TOC can agree on as clarity helps with consensus building, see this as an example: https://github.com/cncf/toc/blob/master/PRINCIPLES.md or https://github.com/cncf/foundation/blob/master/charter.md#3-values

There are good ideas to pull from CNCF and other communities out there, with an opportunity to put your own spin on it.

2) establish a project acceptance/lifecycle process:


I'd start there before worrying about landscapes or new projects, establishing a set of values and process the TOC and the community agrees on is critical. While this discussion is happening, the rest of the TOC will be filled out by the GB over the coming couple months (after the GB meets for the first time next month).

Those are my two cents :)

On Fri, Mar 15, 2019 at 11:01 AM Dan Lorenc via Lists.Cd.Foundation <dlorenc=google.com@...> wrote:
Thanks for sending this! Some thoughts inline, and I look forward to discussing more in person.

On Fri, Mar 15, 2019 at 12:51 PM Kohsuke Kawaguchi <kk@...> wrote:
I'm back to work from the hectic week that is OSLS. As everyone said it before, the launch went really well. Here are some thoughts that I'm starting to form that's relevant to what TOC might want to take on.
  • Several people who are behind some of the "CD" projects came up to me and showed their interest to bring their projects under the CDF. All of them are overlapping to some degree with some of the 4 projects that we already have. That by itself isn't a bad thing, but it did make me wonder how we'd approach them. I feel like the industry and vendors are watching what color this foundation will take in the next few months, and if we build a super market with 4 different kind of apples without any oranges, I don't know if that's the message we want to send.
This came up with me as well. I think we should try to understand the motivations these companies have for placing these projects in a foundation and make sure we have places/levels in place for the broad range of projects/motivations. For example, some companies seem to be motivated by:
  • getting a broader contributor base
  • solving a large industry problem that can't be done in isolation
  • marketing, other project support
  • credibility of being in a foundation
We should prioritize establishing a set of areas where the appropriate type of collaboration can take place for each project. CNCF has sandbox, incubating, graduation, etc. to help. Other foundations have other types of "levels".

A sign of a healthy ecosystem would be projects both inside and outside the foundation interoperating and building on each other. We should also work to dispel any notions that projects must be in the CDF to interoperate with the CDF projects. A CDF landscape would be a big help here. I think Chris said these are pretty easy to setup.

  • But another way to look at this is that the reasons those 4 different apples exist (in various different stages of maturity) is that devops teams needed to scratch their itches, and I'd think a part of the reason is that they weren't aware, or didn't feel comfortable joining other projects. I think we can solve those problems here, and that might encourage more collaboration and result in more consolidation, which I think is a better outcome.

Definitely, vendor-neutral owned projects can be much more welcoming to others. 
  • From there, my mind went to "how do we solve that?" There are a lot of things we can do for sure, and some of those are already mentioned by people when we met. For example, putting people behind those projects together and sharing what problems they are trying to solve to each other would be a great step. Another one I thought is to set a bar or provide help to participating projects about transparency to the governance and/or the vision, which help other organized potential contributors to see if it's aligned with what they need, or they need to build something else. That kind of visibility feels like a sign of maturity anyway.

  • Relevant to above visibility/transparency is that people wanted understand where the collaboration with Tekton and Jenkins are happening and what that means.
 Right! I look forward to having these conversations in central, public discussions hosted by the CDF going forward. They've mostly been informal adhoc meetings so far.
  •  


  • From the "4 different kind of apples without any oranges" thought, another place my head went is that it'd be great to recruit projects more proactively (or at least build relations with.) I think that requires drawing a mental map of the super market, that is the CD space.

  • Finally, completely tangentially, I always thought there are lots of rooms for more API/interop focused small projects. I'm a big fan of Grafeas. Another example is the machine readable input/output to test frameworks --- there's the test report format that JUnit started but now used everywhere from nosetest to rspec, and that could really use a name and a schema.
A few other CDF members expressed interest in Grafeas as well. I'll follow up on this in the next couple of weeks. I think there's definitely a need for a CD-focused, secure metadata standard for interop. 
  • Then I'd love to see a mechanism that allows CI/CD tool to specify a subset of tests to run and its order, for more frictionless parallelism and efficiency. It's all fairly trivial things but it takes putting the right group of people in the room to make happen!!

As you can see, random unorganized thoughts here. Love to hear other people's own thoughts.

--
Kohsuke Kawaguchi



--
Chris Aniszczyk (@cra) | +1-512-961-6719



--
Andrew Glover
Director of Delivery Engineering
Netflix, Inc.



--
Kohsuke Kawaguchi


Chris Aniszczyk
 

Good start, reminder to also fill out the doodle poll for the first meeting:


On Thu, Mar 21, 2019 at 8:35 PM Kohsuke Kawaguchi <kk@...> wrote:
Yes, this is great! I've made one pass. I gotta leave the keyboard now, but I'll come back to this later for more.

On Thu, Mar 21, 2019 at 7:38 AM Andy Glover via Lists.Cd.Foundation <aglover=netflix.com@...> wrote:
This is great, thanks for putting this together, Dan! 

-Andy


On Thu, Mar 21, 2019 at 7:30 AM Dan Lorenc via Lists.Cd.Foundation <dlorenc=google.com@...> wrote:
Thanks Chris! I threw some initial ideas on principles/values, etc. down here. I started with some of the format from the CNCF documents.

On Fri, Mar 15, 2019 at 4:41 PM Chris Aniszczyk <caniszczyk@...> wrote:
I'm happy to see this discussion going on and my advice would be to focus on two things:

1) establish a set of principles/values that the CDF TOC can agree on as clarity helps with consensus building, see this as an example: https://github.com/cncf/toc/blob/master/PRINCIPLES.md or https://github.com/cncf/foundation/blob/master/charter.md#3-values

There are good ideas to pull from CNCF and other communities out there, with an opportunity to put your own spin on it.

2) establish a project acceptance/lifecycle process:


I'd start there before worrying about landscapes or new projects, establishing a set of values and process the TOC and the community agrees on is critical. While this discussion is happening, the rest of the TOC will be filled out by the GB over the coming couple months (after the GB meets for the first time next month).

Those are my two cents :)

On Fri, Mar 15, 2019 at 11:01 AM Dan Lorenc via Lists.Cd.Foundation <dlorenc=google.com@...> wrote:
Thanks for sending this! Some thoughts inline, and I look forward to discussing more in person.

On Fri, Mar 15, 2019 at 12:51 PM Kohsuke Kawaguchi <kk@...> wrote:
I'm back to work from the hectic week that is OSLS. As everyone said it before, the launch went really well. Here are some thoughts that I'm starting to form that's relevant to what TOC might want to take on.
  • Several people who are behind some of the "CD" projects came up to me and showed their interest to bring their projects under the CDF. All of them are overlapping to some degree with some of the 4 projects that we already have. That by itself isn't a bad thing, but it did make me wonder how we'd approach them. I feel like the industry and vendors are watching what color this foundation will take in the next few months, and if we build a super market with 4 different kind of apples without any oranges, I don't know if that's the message we want to send.
This came up with me as well. I think we should try to understand the motivations these companies have for placing these projects in a foundation and make sure we have places/levels in place for the broad range of projects/motivations. For example, some companies seem to be motivated by:
  • getting a broader contributor base
  • solving a large industry problem that can't be done in isolation
  • marketing, other project support
  • credibility of being in a foundation
We should prioritize establishing a set of areas where the appropriate type of collaboration can take place for each project. CNCF has sandbox, incubating, graduation, etc. to help. Other foundations have other types of "levels".

A sign of a healthy ecosystem would be projects both inside and outside the foundation interoperating and building on each other. We should also work to dispel any notions that projects must be in the CDF to interoperate with the CDF projects. A CDF landscape would be a big help here. I think Chris said these are pretty easy to setup.

  • But another way to look at this is that the reasons those 4 different apples exist (in various different stages of maturity) is that devops teams needed to scratch their itches, and I'd think a part of the reason is that they weren't aware, or didn't feel comfortable joining other projects. I think we can solve those problems here, and that might encourage more collaboration and result in more consolidation, which I think is a better outcome.

Definitely, vendor-neutral owned projects can be much more welcoming to others. 
  • From there, my mind went to "how do we solve that?" There are a lot of things we can do for sure, and some of those are already mentioned by people when we met. For example, putting people behind those projects together and sharing what problems they are trying to solve to each other would be a great step. Another one I thought is to set a bar or provide help to participating projects about transparency to the governance and/or the vision, which help other organized potential contributors to see if it's aligned with what they need, or they need to build something else. That kind of visibility feels like a sign of maturity anyway.

  • Relevant to above visibility/transparency is that people wanted understand where the collaboration with Tekton and Jenkins are happening and what that means.
 Right! I look forward to having these conversations in central, public discussions hosted by the CDF going forward. They've mostly been informal adhoc meetings so far.
  •  


  • From the "4 different kind of apples without any oranges" thought, another place my head went is that it'd be great to recruit projects more proactively (or at least build relations with.) I think that requires drawing a mental map of the super market, that is the CD space.

  • Finally, completely tangentially, I always thought there are lots of rooms for more API/interop focused small projects. I'm a big fan of Grafeas. Another example is the machine readable input/output to test frameworks --- there's the test report format that JUnit started but now used everywhere from nosetest to rspec, and that could really use a name and a schema.
A few other CDF members expressed interest in Grafeas as well. I'll follow up on this in the next couple of weeks. I think there's definitely a need for a CD-focused, secure metadata standard for interop. 
  • Then I'd love to see a mechanism that allows CI/CD tool to specify a subset of tests to run and its order, for more frictionless parallelism and efficiency. It's all fairly trivial things but it takes putting the right group of people in the room to make happen!!

As you can see, random unorganized thoughts here. Love to hear other people's own thoughts.

--
Kohsuke Kawaguchi



--
Chris Aniszczyk (@cra) | +1-512-961-6719



--
Andrew Glover
Director of Delivery Engineering
Netflix, Inc.



--
Kohsuke Kawaguchi



--
Chris Aniszczyk (@cra) | +1-512-961-6719


Kohsuke Kawaguchi
 

I wasn't sure how to fit this into a comment of the Google Doc, so instead I'm going to write it here.

I was reading what Dan wrote more carefully, and I thought it'd help to dissect multiple layers in it.
  1. The charter lays out the mission of the CDF. This is what the CDF holds self-evident. This is controlled by the GB, and we the TOC start from here.
  2. There's high level technical values/traits/translation of CD that the TOC holds self-evident. This paints the picture of the practice our projects and their software should enable to users. "Security, reliability, velocity: Pick Three" and the following two bullet items that expands security and velocity maps to this part.
  3. Then there are what the TOC want in software that projects produce. Practicality, Maintainability, Portability, Platform/Stack agnostic sections fit in this layer. Extensibility would be in here as well
  4. Then there are what the TOC want in projects that produce those software. Governance section, what I suggested as a comment as "collaborations" fit in this layer. Openness, fairness belongs here as well.
Does this distinction make sense for others? If so, and if Dan is OK, I'm happy to reorganize the text accordingly.

I think this will help prospective projects understand what the CDF is looking for and how they need to evolve once they join. And that naturally leads to the acceptance criteria and project lifecycle conversations -- that is, we want projects that share the same technical interpretations of CD (#2), projects that are willing to go through the evolution to hit quality software that meets #3, and projects that are willing to evolve its governance to hit #4. The graduation criteria follows from #3 & #4.

That should also serve as a brake pedal for the values to become too numerous and onerous.


On Thu, Mar 21, 2019 at 8:05 AM Kohsuke Kawaguchi <kk@...> wrote:
Yes, this is great! I've made one pass. I gotta leave the keyboard now, but I'll come back to this later for more.

On Thu, Mar 21, 2019 at 7:38 AM Andy Glover via Lists.Cd.Foundation <aglover=netflix.com@...> wrote:
This is great, thanks for putting this together, Dan! 

-Andy


On Thu, Mar 21, 2019 at 7:30 AM Dan Lorenc via Lists.Cd.Foundation <dlorenc=google.com@...> wrote:
Thanks Chris! I threw some initial ideas on principles/values, etc. down here. I started with some of the format from the CNCF documents.

On Fri, Mar 15, 2019 at 4:41 PM Chris Aniszczyk <caniszczyk@...> wrote:
I'm happy to see this discussion going on and my advice would be to focus on two things:

1) establish a set of principles/values that the CDF TOC can agree on as clarity helps with consensus building, see this as an example: https://github.com/cncf/toc/blob/master/PRINCIPLES.md or https://github.com/cncf/foundation/blob/master/charter.md#3-values

There are good ideas to pull from CNCF and other communities out there, with an opportunity to put your own spin on it.

2) establish a project acceptance/lifecycle process:


I'd start there before worrying about landscapes or new projects, establishing a set of values and process the TOC and the community agrees on is critical. While this discussion is happening, the rest of the TOC will be filled out by the GB over the coming couple months (after the GB meets for the first time next month).

Those are my two cents :)

On Fri, Mar 15, 2019 at 11:01 AM Dan Lorenc via Lists.Cd.Foundation <dlorenc=google.com@...> wrote:
Thanks for sending this! Some thoughts inline, and I look forward to discussing more in person.

On Fri, Mar 15, 2019 at 12:51 PM Kohsuke Kawaguchi <kk@...> wrote:
I'm back to work from the hectic week that is OSLS. As everyone said it before, the launch went really well. Here are some thoughts that I'm starting to form that's relevant to what TOC might want to take on.
  • Several people who are behind some of the "CD" projects came up to me and showed their interest to bring their projects under the CDF. All of them are overlapping to some degree with some of the 4 projects that we already have. That by itself isn't a bad thing, but it did make me wonder how we'd approach them. I feel like the industry and vendors are watching what color this foundation will take in the next few months, and if we build a super market with 4 different kind of apples without any oranges, I don't know if that's the message we want to send.
This came up with me as well. I think we should try to understand the motivations these companies have for placing these projects in a foundation and make sure we have places/levels in place for the broad range of projects/motivations. For example, some companies seem to be motivated by:
  • getting a broader contributor base
  • solving a large industry problem that can't be done in isolation
  • marketing, other project support
  • credibility of being in a foundation
We should prioritize establishing a set of areas where the appropriate type of collaboration can take place for each project. CNCF has sandbox, incubating, graduation, etc. to help. Other foundations have other types of "levels".

A sign of a healthy ecosystem would be projects both inside and outside the foundation interoperating and building on each other. We should also work to dispel any notions that projects must be in the CDF to interoperate with the CDF projects. A CDF landscape would be a big help here. I think Chris said these are pretty easy to setup.

  • But another way to look at this is that the reasons those 4 different apples exist (in various different stages of maturity) is that devops teams needed to scratch their itches, and I'd think a part of the reason is that they weren't aware, or didn't feel comfortable joining other projects. I think we can solve those problems here, and that might encourage more collaboration and result in more consolidation, which I think is a better outcome.

Definitely, vendor-neutral owned projects can be much more welcoming to others. 
  • From there, my mind went to "how do we solve that?" There are a lot of things we can do for sure, and some of those are already mentioned by people when we met. For example, putting people behind those projects together and sharing what problems they are trying to solve to each other would be a great step. Another one I thought is to set a bar or provide help to participating projects about transparency to the governance and/or the vision, which help other organized potential contributors to see if it's aligned with what they need, or they need to build something else. That kind of visibility feels like a sign of maturity anyway.

  • Relevant to above visibility/transparency is that people wanted understand where the collaboration with Tekton and Jenkins are happening and what that means.
 Right! I look forward to having these conversations in central, public discussions hosted by the CDF going forward. They've mostly been informal adhoc meetings so far.
  •  


  • From the "4 different kind of apples without any oranges" thought, another place my head went is that it'd be great to recruit projects more proactively (or at least build relations with.) I think that requires drawing a mental map of the super market, that is the CD space.

  • Finally, completely tangentially, I always thought there are lots of rooms for more API/interop focused small projects. I'm a big fan of Grafeas. Another example is the machine readable input/output to test frameworks --- there's the test report format that JUnit started but now used everywhere from nosetest to rspec, and that could really use a name and a schema.
A few other CDF members expressed interest in Grafeas as well. I'll follow up on this in the next couple of weeks. I think there's definitely a need for a CD-focused, secure metadata standard for interop. 
  • Then I'd love to see a mechanism that allows CI/CD tool to specify a subset of tests to run and its order, for more frictionless parallelism and efficiency. It's all fairly trivial things but it takes putting the right group of people in the room to make happen!!

As you can see, random unorganized thoughts here. Love to hear other people's own thoughts.

--
Kohsuke Kawaguchi



--
Chris Aniszczyk (@cra) | +1-512-961-6719



--
Andrew Glover
Director of Delivery Engineering
Netflix, Inc.



--
Kohsuke Kawaguchi



--
Kohsuke Kawaguchi


Dan Lorenc
 

Sounds great to me! I didn't put too much thought into the organization and your layout makes sense to me.

The sections I used for inspiration from the cncf and other documents came from all over.

Dan Lorenc

On Mon, Mar 25, 2019, 7:35 PM Kohsuke Kawaguchi <kk@...> wrote:
I wasn't sure how to fit this into a comment of the Google Doc, so instead I'm going to write it here.

I was reading what Dan wrote more carefully, and I thought it'd help to dissect multiple layers in it.
  1. The charter lays out the mission of the CDF. This is what the CDF holds self-evident. This is controlled by the GB, and we the TOC start from here.
  2. There's high level technical values/traits/translation of CD that the TOC holds self-evident. This paints the picture of the practice our projects and their software should enable to users. "Security, reliability, velocity: Pick Three" and the following two bullet items that expands security and velocity maps to this part.
  3. Then there are what the TOC want in software that projects produce. Practicality, Maintainability, Portability, Platform/Stack agnostic sections fit in this layer. Extensibility would be in here as well
  4. Then there are what the TOC want in projects that produce those software. Governance section, what I suggested as a comment as "collaborations" fit in this layer. Openness, fairness belongs here as well.
Does this distinction make sense for others? If so, and if Dan is OK, I'm happy to reorganize the text accordingly.

I think this will help prospective projects understand what the CDF is looking for and how they need to evolve once they join. And that naturally leads to the acceptance criteria and project lifecycle conversations -- that is, we want projects that share the same technical interpretations of CD (#2), projects that are willing to go through the evolution to hit quality software that meets #3, and projects that are willing to evolve its governance to hit #4. The graduation criteria follows from #3 & #4.

That should also serve as a brake pedal for the values to become too numerous and onerous.


On Thu, Mar 21, 2019 at 8:05 AM Kohsuke Kawaguchi <kk@...> wrote:
Yes, this is great! I've made one pass. I gotta leave the keyboard now, but I'll come back to this later for more.

On Thu, Mar 21, 2019 at 7:38 AM Andy Glover via Lists.Cd.Foundation <aglover=netflix.com@...> wrote:
This is great, thanks for putting this together, Dan! 

-Andy


On Thu, Mar 21, 2019 at 7:30 AM Dan Lorenc via Lists.Cd.Foundation <dlorenc=google.com@...> wrote:
Thanks Chris! I threw some initial ideas on principles/values, etc. down here. I started with some of the format from the CNCF documents.

On Fri, Mar 15, 2019 at 4:41 PM Chris Aniszczyk <caniszczyk@...> wrote:
I'm happy to see this discussion going on and my advice would be to focus on two things:

1) establish a set of principles/values that the CDF TOC can agree on as clarity helps with consensus building, see this as an example: https://github.com/cncf/toc/blob/master/PRINCIPLES.md or https://github.com/cncf/foundation/blob/master/charter.md#3-values

There are good ideas to pull from CNCF and other communities out there, with an opportunity to put your own spin on it.

2) establish a project acceptance/lifecycle process:


I'd start there before worrying about landscapes or new projects, establishing a set of values and process the TOC and the community agrees on is critical. While this discussion is happening, the rest of the TOC will be filled out by the GB over the coming couple months (after the GB meets for the first time next month).

Those are my two cents :)

On Fri, Mar 15, 2019 at 11:01 AM Dan Lorenc via Lists.Cd.Foundation <dlorenc=google.com@...> wrote:
Thanks for sending this! Some thoughts inline, and I look forward to discussing more in person.

On Fri, Mar 15, 2019 at 12:51 PM Kohsuke Kawaguchi <kk@...> wrote:
I'm back to work from the hectic week that is OSLS. As everyone said it before, the launch went really well. Here are some thoughts that I'm starting to form that's relevant to what TOC might want to take on.
  • Several people who are behind some of the "CD" projects came up to me and showed their interest to bring their projects under the CDF. All of them are overlapping to some degree with some of the 4 projects that we already have. That by itself isn't a bad thing, but it did make me wonder how we'd approach them. I feel like the industry and vendors are watching what color this foundation will take in the next few months, and if we build a super market with 4 different kind of apples without any oranges, I don't know if that's the message we want to send.
This came up with me as well. I think we should try to understand the motivations these companies have for placing these projects in a foundation and make sure we have places/levels in place for the broad range of projects/motivations. For example, some companies seem to be motivated by:
  • getting a broader contributor base
  • solving a large industry problem that can't be done in isolation
  • marketing, other project support
  • credibility of being in a foundation
We should prioritize establishing a set of areas where the appropriate type of collaboration can take place for each project. CNCF has sandbox, incubating, graduation, etc. to help. Other foundations have other types of "levels".

A sign of a healthy ecosystem would be projects both inside and outside the foundation interoperating and building on each other. We should also work to dispel any notions that projects must be in the CDF to interoperate with the CDF projects. A CDF landscape would be a big help here. I think Chris said these are pretty easy to setup.

  • But another way to look at this is that the reasons those 4 different apples exist (in various different stages of maturity) is that devops teams needed to scratch their itches, and I'd think a part of the reason is that they weren't aware, or didn't feel comfortable joining other projects. I think we can solve those problems here, and that might encourage more collaboration and result in more consolidation, which I think is a better outcome.

Definitely, vendor-neutral owned projects can be much more welcoming to others. 
  • From there, my mind went to "how do we solve that?" There are a lot of things we can do for sure, and some of those are already mentioned by people when we met. For example, putting people behind those projects together and sharing what problems they are trying to solve to each other would be a great step. Another one I thought is to set a bar or provide help to participating projects about transparency to the governance and/or the vision, which help other organized potential contributors to see if it's aligned with what they need, or they need to build something else. That kind of visibility feels like a sign of maturity anyway.

  • Relevant to above visibility/transparency is that people wanted understand where the collaboration with Tekton and Jenkins are happening and what that means.
 Right! I look forward to having these conversations in central, public discussions hosted by the CDF going forward. They've mostly been informal adhoc meetings so far.
  •  


  • From the "4 different kind of apples without any oranges" thought, another place my head went is that it'd be great to recruit projects more proactively (or at least build relations with.) I think that requires drawing a mental map of the super market, that is the CD space.

  • Finally, completely tangentially, I always thought there are lots of rooms for more API/interop focused small projects. I'm a big fan of Grafeas. Another example is the machine readable input/output to test frameworks --- there's the test report format that JUnit started but now used everywhere from nosetest to rspec, and that could really use a name and a schema.
A few other CDF members expressed interest in Grafeas as well. I'll follow up on this in the next couple of weeks. I think there's definitely a need for a CD-focused, secure metadata standard for interop. 
  • Then I'd love to see a mechanism that allows CI/CD tool to specify a subset of tests to run and its order, for more frictionless parallelism and efficiency. It's all fairly trivial things but it takes putting the right group of people in the room to make happen!!

As you can see, random unorganized thoughts here. Love to hear other people's own thoughts.

--
Kohsuke Kawaguchi



--
Chris Aniszczyk (@cra) | +1-512-961-6719



--
Andrew Glover
Director of Delivery Engineering
Netflix, Inc.



--
Kohsuke Kawaguchi



--
Kohsuke Kawaguchi


kayw@...
 

I am new to these discussions, so please forgive if I mention something that has been discussed or covered elsewhere.

 

Would folks consider modifying the charter slightly to focus on ‘standards and open source software’ … in that order. This might lower the barrier for companies who are, or might be, interested in participating in the foundation for the standards aspect, but are hesitant for one of the following reasons:

 

  1. They don’t currently have open source software to contribute.
  2. They have existing products that compete with some of the initial four projects.

 

Thanks,

Kay

 

From: cdf-toc@... <cdf-toc@...> On Behalf Of Kohsuke Kawaguchi via Lists.Cd.Foundation
Sent: Monday, March 25, 2019 5:35 PM
To: cdf-toc@...
Subject: Re: [cdf-toc] Thoughts from OSLS

 

I wasn't sure how to fit this into a comment of the Google Doc, so instead I'm going to write it here.

 

I was reading what Dan wrote more carefully, and I thought it'd help to dissect multiple layers in it.

  1. The charter lays out the mission of the CDF. This is what the CDF holds self-evident. This is controlled by the GB, and we the TOC start from here.
  2. There's high level technical values/traits/translation of CD that the TOC holds self-evident. This paints the picture of the practice our projects and their software should enable to users. "Security, reliability, velocity: Pick Three" and the following two bullet items that expands security and velocity maps to this part.
  3. Then there are what the TOC want in software that projects produce. Practicality, Maintainability, Portability, Platform/Stack agnostic sections fit in this layer. Extensibility would be in here as well
  4. Then there are what the TOC want in projects that produce those software. Governance section, what I suggested as a comment as "collaborations" fit in this layer. Openness, fairness belongs here as well.

Does this distinction make sense for others? If so, and if Dan is OK, I'm happy to reorganize the text accordingly.

 

I think this will help prospective projects understand what the CDF is looking for and how they need to evolve once they join. And that naturally leads to the acceptance criteria and project lifecycle conversations -- that is, we want projects that share the same technical interpretations of CD (#2), projects that are willing to go through the evolution to hit quality software that meets #3, and projects that are willing to evolve its governance to hit #4. The graduation criteria follows from #3 & #4.

 

That should also serve as a brake pedal for the values to become too numerous and onerous.

 

 

On Thu, Mar 21, 2019 at 8:05 AM Kohsuke Kawaguchi <kk@...> wrote:

Yes, this is great! I've made one pass. I gotta leave the keyboard now, but I'll come back to this later for more.

 

On Thu, Mar 21, 2019 at 7:38 AM Andy Glover via Lists.Cd.Foundation <aglover=netflix.com@...> wrote:

This is great, thanks for putting this together, Dan! 

 

-Andy

 

 

On Thu, Mar 21, 2019 at 7:30 AM Dan Lorenc via Lists.Cd.Foundation <dlorenc=google.com@...> wrote:

Thanks Chris! I threw some initial ideas on principles/values, etc. down here. I started with some of the format from the CNCF documents.

 

On Fri, Mar 15, 2019 at 4:41 PM Chris Aniszczyk <caniszczyk@...> wrote:

I'm happy to see this discussion going on and my advice would be to focus on two things:

 

1) establish a set of principles/values that the CDF TOC can agree on as clarity helps with consensus building, see this as an example: https://github.com/cncf/toc/blob/master/PRINCIPLES.md or https://github.com/cncf/foundation/blob/master/charter.md#3-values

 

There are good ideas to pull from CNCF and other communities out there, with an opportunity to put your own spin on it.

 

2) establish a project acceptance/lifecycle process:

 

 

I'd start there before worrying about landscapes or new projects, establishing a set of values and process the TOC and the community agrees on is critical. While this discussion is happening, the rest of the TOC will be filled out by the GB over the coming couple months (after the GB meets for the first time next month).


Those are my two cents :)

 

On Fri, Mar 15, 2019 at 11:01 AM Dan Lorenc via Lists.Cd.Foundation <dlorenc=google.com@...> wrote:

Thanks for sending this! Some thoughts inline, and I look forward to discussing more in person.

On Fri, Mar 15, 2019 at 12:51 PM Kohsuke Kawaguchi <kk@...> wrote:

I'm back to work from the hectic week that is OSLS. As everyone said it before, the launch went really well. Here are some thoughts that I'm starting to form that's relevant to what TOC might want to take on.

  • Several people who are behind some of the "CD" projects came up to me and showed their interest to bring their projects under the CDF. All of them are overlapping to some degree with some of the 4 projects that we already have. That by itself isn't a bad thing, but it did make me wonder how we'd approach them. I feel like the industry and vendors are watching what color this foundation will take in the next few months, and if we build a super market with 4 different kind of apples without any oranges, I don't know if that's the message we want to send.

This came up with me as well. I think we should try to understand the motivations these companies have for placing these projects in a foundation and make sure we have places/levels in place for the broad range of projects/motivations. For example, some companies seem to be motivated by:

  • getting a broader contributor base
  • solving a large industry problem that can't be done in isolation
  • marketing, other project support
  • credibility of being in a foundation

We should prioritize establishing a set of areas where the appropriate type of collaboration can take place for each project. CNCF has sandbox, incubating, graduation, etc. to help. Other foundations have other types of "levels".

 

A sign of a healthy ecosystem would be projects both inside and outside the foundation interoperating and building on each other. We should also work to dispel any notions that projects must be in the CDF to interoperate with the CDF projects. A CDF landscape would be a big help here. I think Chris said these are pretty easy to setup.

  •  
  • But another way to look at this is that the reasons those 4 different apples exist (in various different stages of maturity) is that devops teams needed to scratch their itches, and I'd think a part of the reason is that they weren't aware, or didn't feel comfortable joining other projects. I think we can solve those problems here, and that might encourage more collaboration and result in more consolidation, which I think is a better outcome.

Definitely, vendor-neutral owned projects can be much more welcoming to others. 

  •  
  • From there, my mind went to "how do we solve that?" There are a lot of things we can do for sure, and some of those are already mentioned by people when we met. For example, putting people behind those projects together and sharing what problems they are trying to solve to each other would be a great step. Another one I thought is to set a bar or provide help to participating projects about transparency to the governance and/or the vision, which help other organized potential contributors to see if it's aligned with what they need, or they need to build something else. That kind of visibility feels like a sign of maturity anyway.
  • Relevant to above visibility/transparency is that people wanted understand where the collaboration with Tekton and Jenkins are happening and what that means.

 Right! I look forward to having these conversations in central, public discussions hosted by the CDF going forward. They've mostly been informal adhoc meetings so far.

  •  

 

  •  
  • From the "4 different kind of apples without any oranges" thought, another place my head went is that it'd be great to recruit projects more proactively (or at least build relations with.) I think that requires drawing a mental map of the super market, that is the CD space.
  • Finally, completely tangentially, I always thought there are lots of rooms for more API/interop focused small projects. I'm a big fan of Grafeas. Another example is the machine readable input/output to test frameworks --- there's the test report format that JUnit started but now used everywhere from nosetest to rspec, and that could really use a name and a schema.

A few other CDF members expressed interest in Grafeas as well. I'll follow up on this in the next couple of weeks. I think there's definitely a need for a CD-focused, secure metadata standard for interop. 

  • Then I'd love to see a mechanism that allows CI/CD tool to specify a subset of tests to run and its order, for more frictionless parallelism and efficiency. It's all fairly trivial things but it takes putting the right group of people in the room to make happen!!

 

As you can see, random unorganized thoughts here. Love to hear other people's own thoughts.

 

--

Kohsuke Kawaguchi


 

--

Chris Aniszczyk (@cra) | +1-512-961-6719


 

--

Andrew Glover

Director of Delivery Engineering

Netflix, Inc.


 

--

Kohsuke Kawaguchi


 

--

Kohsuke Kawaguchi


Chris Aniszczyk
 

Hey Kay, great to have you here!

I don't see how any of those reasons would preclude any organization from joining or participating in any technical discussions (we are not a traditional standards body). If you don't have software to contribute, you're welcome to contribute to TOC meetings with ideas or opening up issues as you see fit, CDF is an open source foundation where technical discussions are open to all. In regards to #2, that's great to hear, that shouldn't cause any issues, we look forward to having the market select what is best for them, but that is outside the role of the foundation.

FYI: modifying the charter takes a 2/3 vote of the Governing Board, this mailing list is for the technical board (TOC) which discusses the overall technical strategy for the CDF. I'm happy to bring up your issue at the next GB meeting next month but the CDF is an open source organization first, with specifications that trail any source code.



On Mon, Mar 25, 2019 at 8:08 PM Kay Williams via Lists.Cd.Foundation <kayw=microsoft.com@...> wrote:

I am new to these discussions, so please forgive if I mention something that has been discussed or covered elsewhere.

 

Would folks consider modifying the charter slightly to focus on ‘standards and open source software’ … in that order. This might lower the barrier for companies who are, or might be, interested in participating in the foundation for the standards aspect, but are hesitant for one of the following reasons:

 

  1. They don’t currently have open source software to contribute.
  2. They have existing products that compete with some of the initial four projects.

 

Thanks,

Kay

 

From: cdf-toc@... <cdf-toc@...> On Behalf Of Kohsuke Kawaguchi via Lists.Cd.Foundation
Sent: Monday, March 25, 2019 5:35 PM
To: cdf-toc@...
Subject: Re: [cdf-toc] Thoughts from OSLS

 

I wasn't sure how to fit this into a comment of the Google Doc, so instead I'm going to write it here.

 

I was reading what Dan wrote more carefully, and I thought it'd help to dissect multiple layers in it.

  1. The charter lays out the mission of the CDF. This is what the CDF holds self-evident. This is controlled by the GB, and we the TOC start from here.
  2. There's high level technical values/traits/translation of CD that the TOC holds self-evident. This paints the picture of the practice our projects and their software should enable to users. "Security, reliability, velocity: Pick Three" and the following two bullet items that expands security and velocity maps to this part.
  3. Then there are what the TOC want in software that projects produce. Practicality, Maintainability, Portability, Platform/Stack agnostic sections fit in this layer. Extensibility would be in here as well
  4. Then there are what the TOC want in projects that produce those software. Governance section, what I suggested as a comment as "collaborations" fit in this layer. Openness, fairness belongs here as well.

Does this distinction make sense for others? If so, and if Dan is OK, I'm happy to reorganize the text accordingly.

 

I think this will help prospective projects understand what the CDF is looking for and how they need to evolve once they join. And that naturally leads to the acceptance criteria and project lifecycle conversations -- that is, we want projects that share the same technical interpretations of CD (#2), projects that are willing to go through the evolution to hit quality software that meets #3, and projects that are willing to evolve its governance to hit #4. The graduation criteria follows from #3 & #4.

 

That should also serve as a brake pedal for the values to become too numerous and onerous.

 

 

On Thu, Mar 21, 2019 at 8:05 AM Kohsuke Kawaguchi <kk@...> wrote:

Yes, this is great! I've made one pass. I gotta leave the keyboard now, but I'll come back to this later for more.

 

On Thu, Mar 21, 2019 at 7:38 AM Andy Glover via Lists.Cd.Foundation <aglover=netflix.com@...> wrote:

This is great, thanks for putting this together, Dan! 

 

-Andy

 

 

On Thu, Mar 21, 2019 at 7:30 AM Dan Lorenc via Lists.Cd.Foundation <dlorenc=google.com@...> wrote:

Thanks Chris! I threw some initial ideas on principles/values, etc. down here. I started with some of the format from the CNCF documents.

 

On Fri, Mar 15, 2019 at 4:41 PM Chris Aniszczyk <caniszczyk@...> wrote:

I'm happy to see this discussion going on and my advice would be to focus on two things:

 

1) establish a set of principles/values that the CDF TOC can agree on as clarity helps with consensus building, see this as an example: https://github.com/cncf/toc/blob/master/PRINCIPLES.md or https://github.com/cncf/foundation/blob/master/charter.md#3-values

 

There are good ideas to pull from CNCF and other communities out there, with an opportunity to put your own spin on it.

 

2) establish a project acceptance/lifecycle process:

 

 

I'd start there before worrying about landscapes or new projects, establishing a set of values and process the TOC and the community agrees on is critical. While this discussion is happening, the rest of the TOC will be filled out by the GB over the coming couple months (after the GB meets for the first time next month).


Those are my two cents :)

 

On Fri, Mar 15, 2019 at 11:01 AM Dan Lorenc via Lists.Cd.Foundation <dlorenc=google.com@...> wrote:

Thanks for sending this! Some thoughts inline, and I look forward to discussing more in person.

On Fri, Mar 15, 2019 at 12:51 PM Kohsuke Kawaguchi <kk@...> wrote:

I'm back to work from the hectic week that is OSLS. As everyone said it before, the launch went really well. Here are some thoughts that I'm starting to form that's relevant to what TOC might want to take on.

  • Several people who are behind some of the "CD" projects came up to me and showed their interest to bring their projects under the CDF. All of them are overlapping to some degree with some of the 4 projects that we already have. That by itself isn't a bad thing, but it did make me wonder how we'd approach them. I feel like the industry and vendors are watching what color this foundation will take in the next few months, and if we build a super market with 4 different kind of apples without any oranges, I don't know if that's the message we want to send.

This came up with me as well. I think we should try to understand the motivations these companies have for placing these projects in a foundation and make sure we have places/levels in place for the broad range of projects/motivations. For example, some companies seem to be motivated by:

  • getting a broader contributor base
  • solving a large industry problem that can't be done in isolation
  • marketing, other project support
  • credibility of being in a foundation

We should prioritize establishing a set of areas where the appropriate type of collaboration can take place for each project. CNCF has sandbox, incubating, graduation, etc. to help. Other foundations have other types of "levels".

 

A sign of a healthy ecosystem would be projects both inside and outside the foundation interoperating and building on each other. We should also work to dispel any notions that projects must be in the CDF to interoperate with the CDF projects. A CDF landscape would be a big help here. I think Chris said these are pretty easy to setup.

  •  
  • But another way to look at this is that the reasons those 4 different apples exist (in various different stages of maturity) is that devops teams needed to scratch their itches, and I'd think a part of the reason is that they weren't aware, or didn't feel comfortable joining other projects. I think we can solve those problems here, and that might encourage more collaboration and result in more consolidation, which I think is a better outcome.

Definitely, vendor-neutral owned projects can be much more welcoming to others. 

  •  
  • From there, my mind went to "how do we solve that?" There are a lot of things we can do for sure, and some of those are already mentioned by people when we met. For example, putting people behind those projects together and sharing what problems they are trying to solve to each other would be a great step. Another one I thought is to set a bar or provide help to participating projects about transparency to the governance and/or the vision, which help other organized potential contributors to see if it's aligned with what they need, or they need to build something else. That kind of visibility feels like a sign of maturity anyway.
  • Relevant to above visibility/transparency is that people wanted understand where the collaboration with Tekton and Jenkins are happening and what that means.

 Right! I look forward to having these conversations in central, public discussions hosted by the CDF going forward. They've mostly been informal adhoc meetings so far.

  •  

 

  •  
  • From the "4 different kind of apples without any oranges" thought, another place my head went is that it'd be great to recruit projects more proactively (or at least build relations with.) I think that requires drawing a mental map of the super market, that is the CD space.
  • Finally, completely tangentially, I always thought there are lots of rooms for more API/interop focused small projects. I'm a big fan of Grafeas. Another example is the machine readable input/output to test frameworks --- there's the test report format that JUnit started but now used everywhere from nosetest to rspec, and that could really use a name and a schema.

A few other CDF members expressed interest in Grafeas as well. I'll follow up on this in the next couple of weeks. I think there's definitely a need for a CD-focused, secure metadata standard for interop. 

  • Then I'd love to see a mechanism that allows CI/CD tool to specify a subset of tests to run and its order, for more frictionless parallelism and efficiency. It's all fairly trivial things but it takes putting the right group of people in the room to make happen!!

 

As you can see, random unorganized thoughts here. Love to hear other people's own thoughts.

 

--

Kohsuke Kawaguchi


 

--

Chris Aniszczyk (@cra) | +1-512-961-6719


 

--

Andrew Glover

Director of Delivery Engineering

Netflix, Inc.


 

--

Kohsuke Kawaguchi


 

--

Kohsuke Kawaguchi



--
Chris Aniszczyk (@cra) | +1-512-961-6719