On Tuesday 13 September 2011 18:45:32 Carl Trieloff wrote:

On 09/13/2011 10:23 AM, Doron Fediuck wrote:

...

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.

I've added this

In addition the board my vote to include additional projects that are complementary to the oVirt eco-system on a case by case basis.

Carl.

ACK with the following minor fix: my=> may -- /d "Who's General Failure and why's he reading my disk?"