Re: Adding a project to oVirt
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(a)ovirt.org
> [mailto:project-planning-bounces@ovirt.org] On Behalf Of Carl
> > Trieloff
> > Sent: Monday, September 12, 2011 22:30 PM
> > To: project-planning(a)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!"