<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
<br>
<br>
On 03/08/16 21:15, Flavio Percoco wrote:<br>
<span style="white-space: pre;">> On 02/08/16 15:13 +0000, Hayes,
Graham wrote:<br>
>> On 02/08/2016 15:42, Flavio Percoco wrote:<br>
>>> On 01/08/16 10:19 -0400, Sean Dague wrote:<br>
>>>> On 08/01/2016 09:58 AM, Davanum Srinivas wrote:<br>
>>>>> Thierry, Ben, Doug,<br>
>>>>><br>
>>>>> How can we distinguish between. "Project is
doing the right thing, but<br>
>>>>> others are not joining" vs "Project is
actively trying to keep people<br>
>>>>> out"?<br>
>>>><br>
>>>> I think at some level, it's not really that
different. If we treat them<br>
>>>> as different, everyone will always believe they
did all the right<br>
>>>> things, but got no results. 3 cycles should be
plenty of time to drop<br>
>>>> single entity contributions below 90%. That means
prioritizing bugs /<br>
>>>> patches from outside groups (to drop below 90% on
code commits),<br>
>>>> mentoring every outside member that provides
feedback (to drop below 90%<br>
>>>> on reviews), shifting development resources
towards mentoring / docs /<br>
>>>> on ramp exercises for others in the community (to
drop below 90% on core<br>
>>>> team).<br>
>>>><br>
>>>> Digging out of a single vendor status is hard,
and requires making that<br>
>>>> your top priority. If teams aren't interested in
putting that ahead of<br>
>>>> development work, that's fine, but that doesn't
make it a sustainable<br>
>>>> OpenStack project.<br>
>>><br>
>>><br>
>>> ++ to the above! I don't think they are that
different either and we might not<br>
>>> need to differentiate them after all.<br>
>>><br>
>>> Flavio<br>
>>><br>
>><br>
>> I do have one question - how are teams getting out of<br>
>> "team:single-vendor" and towards
"team:diverse-affiliation" ?<br>
>><br>
>> We have tried to get more people involved with Designate
using the ways<br>
>> we know how - doing integrations with other projects,
pushing designate<br>
>> at conferences, helping DNS Server vendors to add
drivers, adding<br>
>> drivers for DNS Servers and service providers ourselves,
adding<br>
>> features - the lot.<br>
>><br>
>> We have a lot of user interest (41% of users were
interested in using<br>
>> us), and are quite widely deployed for a non
tc-approved-release<br>
>> project (17% - 5% in production). We are actually the
most deployed<br>
>> non tc-approved-release project.<br>
>><br>
>> We still have 81% of the reviews done by 2 companies, and
83% by 3<br>
>> companies.<br>
>><br>
>> I know our project is not "cool", and DNS is probably one
of the most<br>
>> boring topics, but I honestly believe that it has a place
in the<br>
>> majority of OpenStack clouds - both public and private.
We are a small<br>
>> team of people dedicated to making Designate the best we
can, but are<br>
>> still one company deciding to drop OpenStack / DNS
development from<br>
>> joining the single-vendor party.<br>
>><br>
>> We are definitely interested in putting community
development ahead of<br>
>> development work - but what that actual work is seems to
difficult to<br>
>> nail down. I do feel sometimes that I am flailing in the
dark trying to<br>
>> improve this.<br>
>><br>
>> If projects could share how that got out of single-vendor
or into<br>
>> diverse-affiliation this could really help teams progress
in the<br>
>> community, and avoid being removed.<br>
>><br>
>> Making grand statements about "work harder on community"
without any<br>
>> guidance about what we need to work on do not help the
community.<br>
><br>
> Zaqar has had the same issue ever since the project was
created. The team has<br>
> been actively mentoring folks from the Outreachy program and
Google Summer of<br>
> code whenever possible.<br>
><br>
> Folks from other teams have also contributed to the project
but sometimes these<br>
> folks were also part of the same company as the majority of
Zaqar's<br>
> contributors, which doesn't help much with this.<br>
><br>
> It's not until recently that Zaqar has increased its
diversity but I believe<br>
> it's in the edge and it's also related to the amount (or lack
there of) of<br>
> adoption it's gotten.<br>
></span><br>
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 <a class="moz-txt-link-rfc2396E" href="https://review.openstack.org/342366"><https://review.openstack.org/342366></a>
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.<br>
<br>
<span style="white-space: pre;">> To me, one of the most
important items is engaging with mentees from other<br>
> programs. I see this also as a way to give back to the
communities and the rest<br>
> of the world.<br>
><br>
> Flavio<br>
><br>
><br>
><br>
>
__________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe:
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></span><br>
<br>
- -- <br>
Cheers & Best regards,<br>
Fei Long Wang (王飞龙)<br>
-
--------------------------------------------------------------------------<br>
Senior Cloud Software Engineer<br>
Tel: +64-48032246<br>
Email: <a class="moz-txt-link-abbreviated" href="mailto:flwang@catalyst.net.nz">flwang@catalyst.net.nz</a><br>
Catalyst IT Limited<br>
Level 6, Catalyst House, 150 Willis Street, Wellington<br>
-
--------------------------------------------------------------------------<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1<br>
<br>
iQEcBAEBAgAGBQJXooNAAAoJED4ISAHkpt8cbjIH/1b0hwpkP4cyt841rCnfG5wS<br>
apV5mcYXIcXJFc/pHUCxA4yJC3XtCU15rAOKT050MZ1osKydrE7Fv53uzGocPKP/<br>
m9VonHWjmuPQfFWB5X0VGUP6a1LYXTTuFyAcOU5SoF03+I35MZ4Yzvjc5LLt6Ke5<br>
wekxRu2jmnPN6Q/FBGgCLJ51hz3qnTi5nckDP2Y4seWQ4/1dpW+31V79AvSemCXA<br>
Ky/+rQkHY4TlIt8QPAxM/mf+j9RckNwVLWFx729v/qVFpXsqz/udTp4W5cevrWRw<br>
jGSmdPtxvnZuOiUvrt0pmP1H4z3Ok7oMbKzx4UU+dykemLifCcMYm0L33GqkI/8=<br>
=bpro<br>
-----END PGP SIGNATURE-----<br>
<br>
</body>
</html>