[openstack-dev] [tc] persistently single-vendor projects

Fei Long Wang feilong at catalyst.net.nz
Wed Aug 3 23:50:24 UTC 2016


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 03/08/16 21:15, Flavio Percoco wrote:
> On 02/08/16 15:13 +0000, Hayes, Graham wrote:
>> On 02/08/2016 15:42, Flavio Percoco wrote:
>>> On 01/08/16 10:19 -0400, Sean Dague wrote:
>>>> On 08/01/2016 09:58 AM, Davanum Srinivas wrote:
>>>>> Thierry, Ben, Doug,
>>>>>
>>>>> How can we distinguish between. "Project is doing the right thing, but
>>>>> others are not joining" vs "Project is actively trying to keep people
>>>>> out"?
>>>>
>>>> I think at some level, it's not really that different. If we treat them
>>>> as different, everyone will always believe they did all the right
>>>> things, but got no results. 3 cycles should be plenty of time to drop
>>>> single entity contributions below 90%. That means prioritizing bugs /
>>>> patches from outside groups (to drop below 90% on code commits),
>>>> mentoring every outside member that provides feedback (to drop
below 90%
>>>> on reviews), shifting development resources towards mentoring / docs /
>>>> on ramp exercises for others in the community (to drop below 90% on
core
>>>> team).
>>>>
>>>> Digging out of a single vendor status is hard, and requires making that
>>>> your top priority. If teams aren't interested in putting that ahead of
>>>> development work, that's fine, but that doesn't make it a sustainable
>>>> OpenStack project.
>>>
>>>
>>> ++ to the above! I don't think they are that different either and we
might not
>>> need to differentiate them after all.
>>>
>>> Flavio
>>>
>>
>> I do have one question - how are teams getting out of
>> "team:single-vendor" and towards "team:diverse-affiliation" ?
>>
>> We have tried to get more people involved with Designate using the ways
>> we know how - doing integrations with other projects, pushing designate
>> at conferences, helping DNS Server vendors to add drivers, adding
>> drivers for DNS Servers and service providers ourselves, adding
>> features - the lot.
>>
>> We have a lot of user interest (41% of users were interested in using
>> us), and are quite widely deployed for a non tc-approved-release
>> project (17% - 5% in production). We are actually the most deployed
>> non tc-approved-release project.
>>
>> We still have 81% of the reviews done by 2 companies, and 83% by 3
>> companies.
>>
>> I know our project is not "cool", and DNS is probably one of the most
>> boring topics, but I honestly believe that it has a place in the
>> majority of OpenStack clouds - both public and private. We are a small
>> team of people dedicated to making Designate the best we can, but are
>> still one company deciding to drop OpenStack / DNS development from
>> joining the single-vendor party.
>>
>> We are definitely interested in putting community development ahead of
>> development work - but what that actual work is seems to difficult to
>> nail down. I do feel sometimes that I am flailing in the dark trying to
>> improve this.
>>
>> If projects could share how that got out of single-vendor or into
>> diverse-affiliation this could really help teams progress in the
>> community, and avoid being removed.
>>
>> Making grand statements about "work harder on community" without any
>> guidance about what we need to work on do not help the community.
>
> Zaqar has had the same issue ever since the project was created. The
team has
> been actively mentoring folks from the Outreachy program and Google
Summer of
> code whenever possible.
>
> Folks from other teams have also contributed to the project but
sometimes these
> folks were also part of the same company as the majority of Zaqar's
> contributors, which doesn't help much with this.
>
> It's not until recently that Zaqar has increased its diversity but I
believe
> it's in the edge and it's also related to the amount (or lack there of) of
> adoption it's gotten.
>
As for the adoption, IMHO, it's really depends on the service type and I
think which is one of the main reasons of lacking adoption for some
projects. For example,  you shouldn't expect every cloud deploying a
messaging service, like Zaqar. But every cloud based on OpenStack will
have Nova for sure. So it brings an interesting point,  and I think it's
related to an spec Equal Integration Chances for all Projects
<https://review.openstack.org/342366> In that spec, seems(may I read it
by a wrong way) we got an agreement that not all the projects are equal.
However, we're always applying the same rules for every projects. That's
fine, actually my point is for those projects which are not *equal* as
Nova, Neutron or Cinder, it would be nice if we could give them more
time, more space, more support to help them grow. I would like to say
that again, OpenStack is a cloud ecosystem, the goal is not creating a
better VM-creator. Though it's not good if a project is single-vendor,
it's worse if we lost a useful service on the list, because we(at least
me) want to see a reasonable diversity for the service coverage.

> To me, one of the most important items is engaging with mentees from other
> programs. I see this also as a way to give back to the communities and
the rest
> of the world.
>
> Flavio
>
>
>
> __________________________________________________________________________
> 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

- -- 
Cheers & Best regards,
Fei Long Wang (王飞龙)
- --------------------------------------------------------------------------
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flwang at catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
- --------------------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJXooNAAAoJED4ISAHkpt8cbjIH/1b0hwpkP4cyt841rCnfG5wS
apV5mcYXIcXJFc/pHUCxA4yJC3XtCU15rAOKT050MZ1osKydrE7Fv53uzGocPKP/
m9VonHWjmuPQfFWB5X0VGUP6a1LYXTTuFyAcOU5SoF03+I35MZ4Yzvjc5LLt6Ke5
wekxRu2jmnPN6Q/FBGgCLJ51hz3qnTi5nckDP2Y4seWQ4/1dpW+31V79AvSemCXA
Ky/+rQkHY4TlIt8QPAxM/mf+j9RckNwVLWFx729v/qVFpXsqz/udTp4W5cevrWRw
jGSmdPtxvnZuOiUvrt0pmP1H4z3Ok7oMbKzx4UU+dykemLifCcMYm0L33GqkI/8=
=bpro
-----END PGP SIGNATURE-----

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160804/781ff517/attachment.html>


More information about the OpenStack-dev mailing list