(URL REDACTED - INFO: http://lists.ovirt.org/mailman/project-planning/2011-September/000283.html) Anthony, I believe I have your comments worked into this doc, please take a look. Itamar, please review the two project rules. Carl.
On 09/12/2011 02:30 PM, Carl Trieloff wrote:
(URL REDACTED - INFO: http://lists.ovirt.org/mailman/project-planning/2011-September/000283.html)
Anthony, I believe I have your comments worked into this doc, please take a look.
Itamar, please review the two project rules.
What is a "published API"? Does the board vote on what constitutes a published API, or does any API that is published by an accepted project automatically become an oVirt published API? Regards, Anthony Liguori
Carl. _______________________________________________ Project-planning mailing list Project-planning@ovirt.org http://lists.ovirt.org/mailman/listinfo/project-planning
On 09/12/2011 03:41 PM, Anthony Liguori wrote:
On 09/12/2011 02:30 PM, Carl Trieloff wrote:
(URL REDACTED - INFO: http://lists.ovirt.org/mailman/project-planning/2011-September/000283.html)
Anthony, I believe I have your comments worked into this doc, please take a look.
Itamar, please review the two project rules.
What is a "published API"? Does the board vote on what constitutes a published API, or does any API that is published by an accepted project automatically become an oVirt published API?
I was thinking of votes in term of VDSM, the Admin REST API. or we want to add a reporting API etc. not the contents, just which team drives it, and that it is an agreed point we 'support' with some or other ABI. We should define that out a bit more. Carl.
On 09/12/2011 03:46 PM, Carl Trieloff wrote:
On 09/12/2011 03:41 PM, Anthony Liguori wrote:
On 09/12/2011 02:30 PM, Carl Trieloff wrote:
(URL REDACTED - INFO: http://lists.ovirt.org/mailman/project-planning/2011-September/000283.html)
Anthony, I believe I have your comments worked into this doc, please take a look.
Itamar, please review the two project rules.
What is a "published API"? Does the board vote on what constitutes a published API, or does any API that is published by an accepted project automatically become an oVirt published API?
I was thinking of votes in term of VDSM, the Admin REST API. or we want to add a reporting API etc. not the contents, just which team drives it, and that it is an agreed point we 'support' with some or other ABI.
We should define that out a bit more.
I was trying to understand how something like QEMU would fit into oVirt. Since this requires that the each project consumes or provides a supported API, QEMU exposes an API that it supports (QMP), but it's not published through oVirt (or would it be?). oVirt Engine consumes it via a very indirect path (through VDSM, then through libvirt, and then QMP). I don't think Apache has any real requirement that projects under Apache.org integrates with apache directly, right? Maybe it would be best if we avoided being overly specific here. How does Eclipse handle this? Regards, Anthony Liguori
Carl.
On 09/12/2011 05:02 PM, Anthony Liguori wrote:
On 09/12/2011 03:46 PM, Carl Trieloff wrote:
On 09/12/2011 03:41 PM, Anthony Liguori wrote:
On 09/12/2011 02:30 PM, Carl Trieloff wrote:
(URL REDACTED - INFO: http://lists.ovirt.org/mailman/project-planning/2011-September/000283.html)
Anthony, I believe I have your comments worked into this doc, please take a look.
Itamar, please review the two project rules.
What is a "published API"? Does the board vote on what constitutes a published API, or does any API that is published by an accepted project automatically become an oVirt published API?
I was thinking of votes in term of VDSM, the Admin REST API. or we want to add a reporting API etc. not the contents, just which team drives it, and that it is an agreed point we 'support' with some or other ABI.
We should define that out a bit more.
I was trying to understand how something like QEMU would fit into oVirt.
Since this requires that the each project consumes or provides a supported API, QEMU exposes an API that it supports (QMP), but it's not published through oVirt (or would it be?). oVirt Engine consumes it via a very indirect path (through VDSM, then through libvirt, and then QMP).
that is why I phrased it provides or consume directly or indirectly, to cover these cases. That should cover things like QEMU or other modules down the stack. It also allow for someone to build a proxy or something else ontop of the REST API, and then have a project that uses that project would also be able to be included. The key is that engine is the 'glue' project and then we want to be able to relate all project to it, either on top of the engine, or under it.
I don't think Apache has any real requirement that projects under Apache.org integrates with apache directly, right? Maybe it would be best if we avoided being overly specific here.
No, Apache has not such rule
How does Eclipse handle this?
Eclipse is the model here we want to use for this part. They have a set of frameworks, a core platform which also ships as RCP (the morel equivalent of or engine) and then a set of API. They also have an arch list. All projects have to: - integrate with the core framework (effectively RCP) {this means cut/copy/ paste etc etc all work between the projects for example so between WTP and STP even those there is zero overlap in dev between these projects or between WTP and any 3rd party plugin} then optionally support additional API's - some projects also create API's for consumption, there is an arch team that coordinates and agrees which projects expose project wide supportable API's The second rule is that each project must support the release schedule. the project is free to choose what it is going to put onto the 'release train' as they call it They have a few more rules, but I think we only need these two to get what we need to keep oVirt consistent and simple. As we mature we can as needed. I'll try find some docs on it and mail out the link for reference. Carl.
On 09/13/2011 08:56 AM, Carl Trieloff wrote:
On 09/12/2011 05:02 PM, Anthony Liguori wrote:
On 09/12/2011 03:46 PM, Carl Trieloff wrote:
On 09/12/2011 03:41 PM, Anthony Liguori wrote:
On 09/12/2011 02:30 PM, Carl Trieloff wrote:
(URL REDACTED - INFO: http://lists.ovirt.org/mailman/project-planning/2011-September/000283.html)
Anthony, I believe I have your comments worked into this doc, please take a look.
Itamar, please review the two project rules.
What is a "published API"? Does the board vote on what constitutes a published API, or does any API that is published by an accepted project automatically become an oVirt published API?
I was thinking of votes in term of VDSM, the Admin REST API. or we want to add a reporting API etc. not the contents, just which team drives it, and that it is an agreed point we 'support' with some or other ABI.
We should define that out a bit more.
I was trying to understand how something like QEMU would fit into oVirt.
Since this requires that the each project consumes or provides a supported API, QEMU exposes an API that it supports (QMP), but it's not published through oVirt (or would it be?). oVirt Engine consumes it via a very indirect path (through VDSM, then through libvirt, and then QMP).
that is why I phrased it provides or consume directly or indirectly, to cover these cases. That should cover things like QEMU or other modules down the stack. It also allow for someone to build a proxy or something else ontop of the REST API, and then have a project that uses that project would also be able to be included.
The key is that engine is the 'glue' project and then we want to be able to relate all project to it, either on top of the engine, or under it.
I don't think Apache has any real requirement that projects under Apache.org integrates with apache directly, right? Maybe it would be best if we avoided being overly specific here.
No, Apache has not such rule
How does Eclipse handle this?
Eclipse is the model here we want to use for this part. They have a set of frameworks, a core platform which also ships as RCP (the morel equivalent of or engine) and then a set of API. They also have an arch list. All projects have to:
- integrate with the core framework (effectively RCP) {this means cut/copy/ paste etc etc all work between the projects for example so between WTP and STP even those there is zero overlap in dev between these projects or between WTP and any 3rd party plugin} then optionally support additional API's
- some projects also create API's for consumption, there is an arch team that coordinates and agrees which projects expose project wide supportable API's
The second rule is that each project must support the release schedule. the project is free to choose what it is going to put onto the 'release train' as they call it
They have a few more rules, but I think we only need these two to get what we need to keep oVirt consistent and simple. As we mature we can as needed.
I'll try find some docs on it and mail out the link for reference.
Thanks, this is helpful background info. Regards, Anthony Liguori
Carl.
On 09/12/2011 02:30 PM, Carl Trieloff wrote:
(URL REDACTED - INFO: http://lists.ovirt.org/mailman/project-planning/2011-September/000283.html)
Anthony, I believe I have your comments worked into this doc, please take a look.
Itamar, please review the two project rules.
For this paragraph: "In order to release a cohesive stack, everything needs to work together. The core of this is the engine. If a new project is started it needs to integrate with a published API, or an additional API needs to be created into the engine project to support the new project. Finally additional API’s can come into scope to provide facilities/capabilities that the engine consumes. The board signs off on which project provide API’s to make sure there is coordination between the projects. The board is not responsible for the technical aspects of the API’s, just the facilitation when named API projects are added or removed." It feels a bit out of place. Perhaps it's because I don't have a good grip on what the "engine project" is since it still doesn't exist as an open source project. Maybe we can just drop this paragraph or remove the bits about the engine? The rest looks great. Regards, Anthony Liguori
Carl. _______________________________________________ Project-planning mailing list Project-planning@ovirt.org http://lists.ovirt.org/mailman/listinfo/project-planning
On 09/12/2011 03:45 PM, Anthony Liguori wrote:
"In order to release a cohesive stack, everything needs to work together. The core of this is the engine. If a new project is started it needs to integrate with a published API, or an additional API needs to be created into the engine project to support the new project. Finally additional API’s can come into scope to provide facilities/capabilities that the engine consumes. The board signs off on which project provide API’s to make sure there is coordination between the projects. The board is not responsible for the technical aspects of the API’s, just the facilitation when named API projects are added or removed."
It feels a bit out of place. Perhaps it's because I don't have a good grip on what the "engine project" is since it still doesn't exist as an open source project.
Maybe we can just drop this paragraph or remove the bits about the engine? The rest looks great.
The engine is the core framework for us, as I posted in the piece on how eclipse works. I would like to add it and we can discuss in more detail in the governance tracks at the workshop and edit as required. However to the point on related projects, I'm going to add a para on that Carl.
On 09/13/2011 10:42 AM, Carl Trieloff wrote:
On 09/12/2011 03:45 PM, Anthony Liguori wrote:
"In order to release a cohesive stack, everything needs to work together. The core of this is the engine. If a new project is started it needs to integrate with a published API, or an additional API needs to be created into the engine project to support the new project. Finally additional API’s can come into scope to provide facilities/capabilities that the engine consumes. The board signs off on which project provide API’s to make sure there is coordination between the projects. The board is not responsible for the technical aspects of the API’s, just the facilitation when named API projects are added or removed."
It feels a bit out of place. Perhaps it's because I don't have a good grip on what the "engine project" is since it still doesn't exist as an open source project.
Maybe we can just drop this paragraph or remove the bits about the engine? The rest looks great.
The engine is the core framework for us, as I posted in the piece on how eclipse works. I would like to add it and we can discuss in more detail in the governance tracks at the workshop and edit as required.
Okay, it makes sense re: eclipse but I think we need to come up with a firm mission statement of the engine project. The way it's positioned, if RHEV-M Server is oVirt Engine, then you're excluding the possibility of having an stand alone VDSM with tools that build directly on top of VDSM. If that's the case, then it dramatically affects the type of ecosystem being built here. Regards, Anthony Liguori
However to the point on related projects, I'm going to add a para on that
Carl.
-----Original Message----- From: project-planning-bounces@ovirt.org [mailto:project-planning-bounces@ovirt.org] On Behalf Of Carl Trieloff Sent: Monday, September 12, 2011 22:30 PM To: project-planning@ovirt.org Subject: Adding a project to oVirt
(URL REDACTED - INFO: http://lists.ovirt.org/mailman/project-planning/2011-September/000283.html)
Anthony, I believe I have your comments worked into this doc, please take a look.
Itamar, please review the two project rules.
Looks ok to me, my concerns are on the rules implied by this, but that's on another thread. Cc'ing more reviewers
On Tuesday 13 September 2011 11:24:16 Itamar Heim wrote:
-----Original Message----- From: project-planning-bounces@ovirt.org [mailto:project-planning-bounces@ovirt.org] On Behalf Of Carl Trieloff Sent: Monday, September 12, 2011 22:30 PM To: project-planning@ovirt.org Subject: Adding a project to oVirt
(URL REDACTED - INFO: http://lists.ovirt.org/mailman/project-planning/2011-September/000283.html)
Anthony, I believe I have your comments worked into this doc, please take a look.
Itamar, please review the two project rules.
Looks ok to me, my concerns are on the rules implied by this, but that's on another thread. Cc'ing more reviewers
The API restriction may be too much. Assuming engine is RHEV-M, important projects similar to KSM[1] will not be a part of oVirt, and we may end up loosing important innovations. I'm not sure RHEV-M (engine) is fully equivalent to eclipse, and therefore the API rule may harm us. As I see it, either we define oVirt umbrella as an union model (rings around rhev-m), and acknowledge the fact we'll be loosing projects, or use an eco-environment for visualization, by restricting the API rule to engin-related project, and accepting other project which will commit to the other eco-system rule(s). [1] http://www.linux-kvm.com/content/using-ksm-kernel-samepage-merging-kvm -- /d "Do not look into laser with remaining eye." --On a laser pointer user-manual
On Tuesday 13 September 2011 17:11:47 Doron Fediuck wrote:
On Tuesday 13 September 2011 11:24:16 Itamar Heim wrote:
-----Original Message----- From: project-planning-bounces@ovirt.org [mailto:project-planning-bounces@ovirt.org] On Behalf Of Carl Trieloff Sent: Monday, September 12, 2011 22:30 PM To: project-planning@ovirt.org Subject: Adding a project to oVirt
(URL REDACTED - INFO: http://lists.ovirt.org/mailman/project-planning/2011-September/000283.html)
Anthony, I believe I have your comments worked into this doc, please take a look.
Itamar, please review the two project rules.
Looks ok to me, my concerns are on the rules implied by this, but that's on another thread. Cc'ing more reviewers
The API restriction may be too much. Assuming engine is RHEV-M, important projects similar to KSM[1] will not be a part of oVirt, and we may end up loosing important innovations.
I'm not sure RHEV-M (engine) is fully equivalent to eclipse, and therefore the API rule may harm us.
As I see it, either we define oVirt umbrella as an union model (rings around rhev-m), and acknowledge the fact we'll be loosing projects, or use an eco-environment for visualization, by restricting the API rule to engin-related project, and accepting other project which will commit to the other eco-system rule(s).
Sorry for mail my previous typo's (visualization -> virtualization, engin->engine, etc). One more thing I left out; What I'm missing in this document is a review process to a new project. IE- Do we accept any new project or do we have some minimal 'due diligence' of the project. For example; - Who owns it? - Is there some commitment behind it, or is it a 'one man show'? - Does is have a malicious potential? These are all examples I hope we won't need to face. I think it should be considered and added into the document, if you feel the same. -- /d "Willyoupleasehelpmefixmykeyboard?Thespacebarisbroken!"
participants (4)
-
Anthony Liguori -
Carl Trieloff -
Doron Fediuck -
Itamar Heim