|
All,
Issues I heard today:
1. would be good to talk about some fundamental assumptions about what we think about standards (which is part of the OCI mandate) - suggest we involve the GB in this. also: there are related topics - service broker, volumes... E.g.: the TOC needs to decide if a project can be "just a spec", or does it need to be "mainly code that just happens to have a spec".
2. invite some CNI stakeholders, not on TOC, to give us the "project point of view" -- eg metaswitch, redhat?
3. perception, brand and timing are issues; would be good to get some more projects on board that aren't 'glue' or 'interface' type things.
Summary:
So let's separate the discussion:
A) type of acceptable work/projects in CNCF vs B) is CNI a good fit.
We need to resolve A independently of B, and can get going first on A. But, eg in parallel, I think it would be fair to hear from a CNI lead (or two) who is not on TOC.
|
|
|
Stefan Junker <stefan.junker@...>
Hi, I’m one of the maintainers of CNI. I was on the CNCF call yesterday during which understood only TOC members should state their opinion, so I decided to just listen and write down my thoughts afterwards. Although CNI is a small project it has been around for a while, and since I joined, the goal has transitioned away from the initial statement which was still captured in the README. Shortly after the call I submitted a small but significant change [1] which I hope will clarify the position of the project. We, the maintainers, don’t want to make CNI a blessed standard. Instead, we hold great value in the specification that has already allowed many projects to use the flexible plugin system for developing and interconnecting simple to complex container networking solutions. Our hope is that the CNCF provides a stable, vendor-neutral brand and home to foster these values, so that even more developers feel comfortable to help improve the quality of existing code and upstream their plugin code. Thanks for your attention! I will also be happy to answer any questions that the TOC has about the project. Stefan Junker [1]: https://github.com/appc/cni/pull/186
|
|
|
re: topic "A" - acceptable CNCF projects
IMO the CNCF should allow a variety of types of projects. Ranging from ones that are pure "code" to ones that are just "specifications". While pure spec projects aren't nearly as interesting to me, I'm not comfortable with the idea what we outright ban them. They do have a place in the bigger picture especially if people want to use CNCF as a place to do harmonization type of work and trying to develop a joint spec is the first step in that process.
I'd prefer if we looked for ways to include more projects (as long as they fit the technical aspects of CNCF's scope), instead of trying to define a high bar for acceptance. We're supposed to be here to help/promote CN technology, in all its forms.
re: CNI
To the CNI issues mentioned yesterday, personally, I don't think it matters that in its README CNI mentioned wanting to be a standard. Its interesting that it has since been removed, but given that CNCF is not a standards producing body that sentence meant nothing to me. In fact, if the authors of a spec that's under the CNCF umbrella wanted to take it to w3c, oasis, ietf, etc... to get that formal standardization, that's their choice and IMO shouldn't impact whether they can remain a CNCF project. To imply that a spec that's been developed under CNCF can not be taken down that path feels pretty limiting and should be out of the CNCF's control. In fact, I would argue that if a CNCF spec was so popular and widely adopted that it became a "real standard" it would actually be a good thing and would show CNCF's value over the traditional paper-only standards process.
Let's evaluate CNI on whether its within the scope of CNCF's CN work, and whether the benefits to both sides makes sense.
thanks
-Doug Davis
_______________________________________________________
STSM | IBM Open Source, Cloud Architecture & Technology
(919) 254-6905 | IBM 444-6905 | dug@...
The more I'm around some people, the more I like my dog
 Alexis Richardson via cncf-toc ---04/20/2016 12:03:18 PM---All, Issues I heard today:
From: Alexis Richardson via cncf-toc <cncf-toc@...>
To: cncf-toc@...
Date: 04/20/2016 12:03 PM
Subject: [cncf-toc] CNI discussion - actions
Sent by: cncf-toc-bounces@...
All, Issues I heard today: 1. would be good to talk about some fundamental assumptions about what we think about standards (which is part of the OCI mandate) - suggest we involve the GB in this. also: there are related topics - service broker, volumes... E.g.: the TOC needs to decide if a project can be "just a spec", or does it need to be "mainly code that just happens to have a spec". 2. invite some CNI stakeholders, not on TOC, to give us the "project point of view" -- eg metaswitch, redhat? 3. perception, brand and timing are issues; would be good to get some more projects on board that aren't 'glue' or 'interface' type things. Summary: So let's separate the discussion: A) type of acceptable work/projects in CNCF vs B) is CNI a good fit. We need to resolve A independently of B, and can get going first on A. But, eg in parallel, I think it would be fair to hear from a CNI lead (or two) who is not on TOC. alexis _______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc
|
|
|
Chris Aniszczyk
On top of what Doug said, I'd like to remind the TOC on what's in the charter currently around projects (section 9): https://cncf.io/governance
9. CNCF Projects (a) It is expected that member companies, and open source community members will bring project assets to the TOC for discussion and inclusion into the CNCF. All such contributions should meet a set criteria created by the TOC and ratified by the Governing Board. The goal is to have an increasing bazaar of projects related to and that integrate with projects already accepted into the CNCF.
(b) Projects can be associated with the CNCF in the following 3 ways: i. Included in CNCF, under a neutral home for collaboration a. All aspects of the project are governed by the CNCF
b. The project is marketed by the CNCF as a CNCF project
c. The project should be a core functional component of the CNCF solution. (e.g. such as Kubernetes, Mesos, etcd, etc.) ii. Associated with the CNCF via an API or specification a. Includes components where the CNCF may offer or enable multiple options
b. The project is referred to as a component that the CNCF integrates with, not as a project hosted by the CNCF
c. Integration and compliance are defined by an API or specification
d. Active development on the project or component is ideally done in the upstream community iii. Used by the CNCF a. A project or component that is completely licensed under an OSI approved open source license and is well managed and used as a component in the CNCF
b. Project is not actively marketed by the CNCF,
c. Active development on the project or component is ideally done in the upstream community (c) Existing open source projects should continue to run through their existing technical governance structure to maintain cohesion and velocity. Projects approved by the TOC for inclusion in the CNCF will be ‘lightly’ subject to the Technical Oversight
Committee.
(d) A standard protocol to achieve committer status shall be established across projects based on an individual’s level and duration of contribution. Maintainer status is achieved through contribution to a given project over time and validation by peer
committers.
(e) New open source projects initiated in CNCF shall complete a project proposal template adopted by the TOC and be approved by the TOC for inclusion in CNCF. The TOC members shall be afforded sufficient time to discuss and review new project proposals. New project proposals shall include details of the roles in the project, the governance proposed for the project and identify alignment with CNCF’s role and values.
On Thu, Apr 21, 2016 at 2:14 PM, Doug Davis via cncf-toc <cncf-toc@...> wrote: re: topic "A" - acceptable CNCF projects
IMO the CNCF should allow a variety of types of projects. Ranging from ones that are pure "code" to ones that are just "specifications". While pure spec projects aren't nearly as interesting to me, I'm not comfortable with the idea what we outright ban them. They do have a place in the bigger picture especially if people want to use CNCF as a place to do harmonization type of work and trying to develop a joint spec is the first step in that process.
I'd prefer if we looked for ways to include more projects (as long as they fit the technical aspects of CNCF's scope), instead of trying to define a high bar for acceptance. We're supposed to be here to help/promote CN technology, in all its forms.
re: CNI
To the CNI issues mentioned yesterday, personally, I don't think it matters that in its README CNI mentioned wanting to be a standard. Its interesting that it has since been removed, but given that CNCF is not a standards producing body that sentence meant nothing to me. In fact, if the authors of a spec that's under the CNCF umbrella wanted to take it to w3c, oasis, ietf, etc... to get that formal standardization, that's their choice and IMO shouldn't impact whether they can remain a CNCF project. To imply that a spec that's been developed under CNCF can not be taken down that path feels pretty limiting and should be out of the CNCF's control. In fact, I would argue that if a CNCF spec was so popular and widely adopted that it became a "real standard" it would actually be a good thing and would show CNCF's value over the traditional paper-only standards process.
Let's evaluate CNI on whether its within the scope of CNCF's CN work, and whether the benefits to both sides makes sense.
thanks
-Doug Davis
_______________________________________________________
STSM | IBM Open Source, Cloud Architecture & Technology
(919) 254-6905 | IBM 444-6905 | dug@...
The more I'm around some people, the more I like my dog
 Alexis Richardson via cncf-toc ---04/20/2016 12:03:18 PM---All, Issues I heard today:
From: Alexis Richardson via cncf-toc <cncf-toc@...>
To: cncf-toc@...
Date: 04/20/2016 12:03 PM
Subject: [cncf-toc] CNI discussion - actions
Sent by: cncf-toc-bounces@...
All, Issues I heard today: 1. would be good to talk about some fundamental assumptions about what we think about standards (which is part of the OCI mandate) - suggest we involve the GB in this. also: there are related topics - service broker, volumes... E.g.: the TOC needs to decide if a project can be "just a spec", or does it need to be "mainly code that just happens to have a spec". 2. invite some CNI stakeholders, not on TOC, to give us the "project point of view" -- eg metaswitch, redhat? 3. perception, brand and timing are issues; would be good to get some more projects on board that aren't 'glue' or 'interface' type things. Summary: So let's separate the discussion: A) type of acceptable work/projects in CNCF vs B) is CNI a good fit. We need to resolve A independently of B, and can get going first on A. But, eg in parallel, I think it would be fair to hear from a CNI lead (or two) who is not on TOC. alexis _______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc
_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc
-- Chris Aniszczyk (@cra) | +1-512-961-6719
|
|
|
Doug
I think the main worry is "ex ante and de jure standards", i.e.: - created ahead of real adoption & maturation of use cases - by a legislature with wide authority
I know that Craig liked to say the TOC was like the supreme court (!) for CNCF, but I think we need to be very humble about our reach.
I am OK with standards emerging "ex post and de re". After the fact, and as a matter of fact.
That doesn't mean we cannot have interop & glue & documents in the CNCF. We just need to figure out how to do that. Carefully.
a
On Thu, Apr 21, 2016 at 8:14 PM, Doug Davis <dug@...> wrote: re: topic "A" - acceptable CNCF projects
IMO the CNCF should allow a variety of types of projects. Ranging from ones that are pure "code" to ones that are just "specifications". While pure spec projects aren't nearly as interesting to me, I'm not comfortable with the idea what we outright ban them. They do have a place in the bigger picture especially if people want to use CNCF as a place to do harmonization type of work and trying to develop a joint spec is the first step in that process.
I'd prefer if we looked for ways to include more projects (as long as they fit the technical aspects of CNCF's scope), instead of trying to define a high bar for acceptance. We're supposed to be here to help/promote CN technology, in all its forms.
re: CNI
To the CNI issues mentioned yesterday, personally, I don't think it matters that in its README CNI mentioned wanting to be a standard. Its interesting that it has since been removed, but given that CNCF is not a standards producing body that sentence meant nothing to me. In fact, if the authors of a spec that's under the CNCF umbrella wanted to take it to w3c, oasis, ietf, etc... to get that formal standardization, that's their choice and IMO shouldn't impact whether they can remain a CNCF project. To imply that a spec that's been developed under CNCF can not be taken down that path feels pretty limiting and should be out of the CNCF's control. In fact, I would argue that if a CNCF spec was so popular and widely adopted that it became a "real standard" it would actually be a good thing and would show CNCF's value over the traditional paper-only standards process.
Let's evaluate CNI on whether its within the scope of CNCF's CN work, and whether the benefits to both sides makes sense.
thanks
-Doug Davis
_______________________________________________________
STSM | IBM Open Source, Cloud Architecture & Technology
(919) 254-6905 | IBM 444-6905 | dug@...
The more I'm around some people, the more I like my dog
 Alexis Richardson via cncf-toc ---04/20/2016 12:03:18 PM---All, Issues I heard today:
From: Alexis Richardson via cncf-toc <cncf-toc@...>
To: cncf-toc@...
Date: 04/20/2016 12:03 PM
Subject: [cncf-toc] CNI discussion - actions
Sent by: cncf-toc-bounces@...
All,
Issues I heard today:
1. would be good to talk about some fundamental assumptions about what we think about standards (which is part of the OCI mandate) - suggest we involve the GB in this. also: there are related topics - service broker, volumes... E.g.: the TOC needs to decide if a project can be "just a spec", or does it need to be "mainly code that just happens to have a spec".
2. invite some CNI stakeholders, not on TOC, to give us the "project point of view" -- eg metaswitch, redhat?
3. perception, brand and timing are issues; would be good to get some more projects on board that aren't 'glue' or 'interface' type things.
Summary:
So let's separate the discussion:
A) type of acceptable work/projects in CNCF
vs
B) is CNI a good fit.
We need to resolve A independently of B, and can get going first on A. But, eg in parallel, I think it would be fair to hear from a CNI lead (or two) who is not on TOC.
alexis _______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc
|
|
|
|
|
|
|
|
|
Stefan Junker <stefan.junker@...>
Brian, Thanks for your suggestion which has been put into action already! The CNI project is now the lonesome member of the "containernetworking" organization on Github [1]. We (the CNI maintainers) are still very interested in working more closely with the CNCF and are happy to receive further technical and organizational feedback. Best Regards Stefan [1]: https://github.com/containernetworking/cni
On 04/27/2016 08:35 PM, Brian Grant wrote: On Thu, Apr 21, 2016 at 8:02 AM, Stefan Junker via cncf-toc
<cncf-toc@... <mailto:cncf-toc@...>> wrote:
Hi,
I’m one of the maintainers of CNI. I was on the CNCF call yesterday
during which understood only TOC members should state their opinion, so
I decided to just listen and write down my thoughts afterwards.
Although CNI is a small project it has been around for a while, and
since I joined, the goal has transitioned away from the initial
statement which was still captured in the README. Shortly after the call
I submitted a small but significant change [1] which I hope will clarify
the position of the project.
We, the maintainers, don’t want to make CNI a blessed standard. Instead,
we hold great value in the specification that has already allowed many
projects to use the flexible plugin system for developing and
interconnecting simple to complex container networking solutions.
Our hope is that the CNCF provides a stable, vendor-neutral brand and
home to foster these values, so that even more developers feel
comfortable to help improve the quality of existing code and upstream
their plugin code.
As a next step, for now, if you'd like to create a more neutral brand, I
recommend moving the project to its own github org. Practically
speaking, that would make the project easier to manage, also.
Thanks for your attention! I will also be happy to answer any questions
that the TOC has about the project.
Stefan Junker
[1]: https://github.com/appc/cni/pull/186
_______________________________________________
cncf-toc mailing list
cncf-toc@... <mailto:cncf-toc@...>
https://lists.cncf.io/mailman/listinfo/cncf-toc
|
|
|
Great. Hopefully it will prove helpful.
In general, github is optimized for small, single-purpose repos (to the extent that it's optimized for anything).
You might also consider creating a separate repo just for issues.
And maybe another if you want to have a wiki.
More generally, I'm not sure if there is a "guide to using github effectively for advanced users / large projects", but such a thing would be useful.
On Wed, May 4, 2016 at 8:24 AM, Stefan Junker <stefan.junker@...> wrote: Brian,
Thanks for your suggestion which has been put into action already!
The CNI project is now the lonesome member of the "containernetworking"
organization on Github [1].
We (the CNI maintainers) are still very interested in working more
closely with the CNCF and are happy to receive further technical and
organizational feedback.
Best Regards
Stefan
[1]: https://github.com/containernetworking/cni
On 04/27/2016 08:35 PM, Brian Grant wrote:
> On Thu, Apr 21, 2016 at 8:02 AM, Stefan Junker via cncf-toc
> < cncf-toc@... <mailto: cncf-toc@...>> wrote:
>
> Hi,
>
> I’m one of the maintainers of CNI. I was on the CNCF call yesterday
> during which understood only TOC members should state their opinion, so
> I decided to just listen and write down my thoughts afterwards.
>
> Although CNI is a small project it has been around for a while, and
> since I joined, the goal has transitioned away from the initial
> statement which was still captured in the README. Shortly after the call
> I submitted a small but significant change [1] which I hope will clarify
> the position of the project.
>
> We, the maintainers, don’t want to make CNI a blessed standard. Instead,
> we hold great value in the specification that has already allowed many
> projects to use the flexible plugin system for developing and
> interconnecting simple to complex container networking solutions.
>
> Our hope is that the CNCF provides a stable, vendor-neutral brand and
> home to foster these values, so that even more developers feel
> comfortable to help improve the quality of existing code and upstream
> their plugin code.
>
>
> As a next step, for now, if you'd like to create a more neutral brand, I
> recommend moving the project to its own github org. Practically
> speaking, that would make the project easier to manage, also.
>
>
>
>
> Thanks for your attention! I will also be happy to answer any questions
> that the TOC has about the project.
>
> Stefan Junker
>
> [1]: https://github.com/appc/cni/pull/186
>
>
> _______________________________________________
> cncf-toc mailing list
> https://lists.cncf.io/mailman/listinfo/cncf-toc
>
>
|
|
|
