Open Stack

Hi Assaf,

I think that if we define a certain criteria we need to make sure that it
applies to everyone equally.
and it is well understood.
I have contributed and still am to both OVN and Dragonflow and hope to
continue do so in the future,
i want to see both of these solutions become a great production grade open
source alternatives.

I have less experience in open source and in this community from most of
you, but from what i saw users
do take these things into consideration, its hard for a new user and even
not so new to understand the possibilities correctly
specially if we cant even define them ourselves

Instead of spending time on technology and on solving the problems for our
users we are concentrating
on this conversation, we haven't even talked about production maturity,
feature richness and stability as you say
and by doing this move, we are signaling something else for our users
without actually discussing about all the
former ourselves.

I will be ok with what ever the Neutron team decide on this, as they can
define the criteria as they please.
Just shared my opinion on this process and my disappointment from it as
someone who values open source
a lot.

Gal.


On Thu, Feb 4, 2016 at 11:31 AM, Assaf Muller <amuller at redhat.com> wrote:

> On Thu, Feb 4, 2016 at 10:20 AM, Assaf Muller <amuller at redhat.com> wrote:
> > On Thu, Feb 4, 2016 at 8:33 AM, Gal Sagie <gal.sagie at gmail.com> wrote:
> >> As i have commented on the patch i will also send this to the mailing
> list:
> >>
> >> I really dont see why Dragonflow is not part of this list, given the
> >> criteria you listed.
> >>
> >> Dragonflow is fully developed under Neutron/OpenStack, no other
> >> repositories. It is fully Open source and already have a community of
> people
> >> contributing and interest from various different companies and OpenStack
> >> deployers. (I can prepare the list of active contributions and of
> interested
> >> parties) It also puts OpenStack Neutron APIs and use cases as first
> class
> >> citizens and working on being an integral part of OpenStack.
> >>
> >> I agree that OVN needs to be part of the list, but you brought up this
> >> criteria in regards to ODL, so: OVN like ODL is not only Neutron and
> >> OpenStack and is even running/being implemented on a whole different
> >> governance model and requirements to it.
> >>
> >> I think you also forgot to mention some other projects as well that are
> >> fully open source with a vibrant and diverse community, i will let them
> >> comment here by themselves.
> >>
> >> Frankly this approach disappoints me, I have honestly worked hard to
> make
> >> Dragonflow fully visible and add and support open discussion and follow
> the
> >> correct guidelines to work in a project. I think that Dragonflow
> community
> >> has already few members from various companies and this is only going to
> >> grow in the near future. (in addition to deployers that are considering
> it
> >> as a solution)  we also welcome anyone that wants to join and be part
> of the
> >> process to step in, we are very welcoming
> >>
> >> I also think that the correct way to do this is to actually add as
> reviewers
> >> all lieutenants of the projects you are now removing from Neutron big
> >> stadium and letting them comment.
> >>
> >> Gal.
> >
> > I understand you see 'Dragonflow being part of the Neutron stadium'
> > and 'Dragonflow having high visibility' as tied together. I'm curious,
> > from a practical perspective, how does being a part of the stadium
> > give Dragonflow visibility? If it were not a part of the stadium and
> > you had your own PTL etc, what specifically would change so that
> > Dragonflow would be less visible. Currently I don't understand why
> > being a part of the stadium is good or bad for a networking project,
> > or why does it matter. Looking at Russell's patch, it's concerned with
> > placing projects (e.g. ODL, OVN, Dragonflow) either in or out of the
> > stadium and the criteria for doing so, I'm just asking how do you
> > (Gal) perceive the practical effect of that decision.
>
> Allow me to expand:
> It seems to me like there is no significance to who is 'in or out'.
> However, people, including potential customers, look at the list of
> the Neutron stadium and deduce that project X is better than Y because
> X is in but Y is out, and *that* in itself is the value of being in or
> out, even though it has no meaning. Maybe we should explain what
> exactly does it mean being in or out. It's just a governance decision,
> it doesn't reflect in any way of the quality or appeal of a project
> (For example some of the open source Neutron drivers out of the
> stadium are much more mature, stable and feature full than other
> drivers in the stadium).
>
> >
> >>
> >>
> >> On Wed, Feb 3, 2016 at 11:48 PM, Russell Bryant <rbryant at redhat.com>
> wrote:
> >>>
> >>> On 11/30/2015 07:56 PM, Armando M. wrote:
> >>> > I would like to suggest that we evolve the structure of the Neutron
> >>> > governance, so that most of the deliverables that are now part of the
> >>> > Neutron stadium become standalone projects that are entirely
> >>> > self-governed (they have their own core/release teams, etc).
> >>>
> >>> After thinking over the discussion in this thread for a while, I have
> >>> started the following proposal to implement the stadium renovation that
> >>> Armando originally proposed in this thread.
> >>>
> >>> https://review.openstack.org/#/c/275888
> >>>
> >>> --
> >>> Russell Bryant
> >>>
> >>>
> __________________________________________________________________________
> >>> OpenStack Development Mailing List (not for usage questions)
> >>> Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >>
> >>
> >> --
> >> Best Regards ,
> >>
> >> The G.
> >>
> >>
> __________________________________________________________________________
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best Regards ,

The G.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160204/9cefc4cf/attachment.html>