[OpenDaylight TSC] [VOTE] TSC Election RGs

Colin Dixon colin at colindixon.com
Thu Sep 8 21:35:44 UTC 2016


That's 6 +1 votes, so this also carries.

I'll try to start a Condorcet vote about allocating seats to RGs tonight or
tomorrow.

--Colin


On Thu, Sep 8, 2016 at 3:14 PM, Anil Vishnoi <vishnoianil at gmail.com> wrote:

> +1
>
> Sent from my iPhone
>
> On Sep 8, 2016, at 10:16 AM, Colin Dixon <colin at colindixon.com> wrote:
>
> With Abhijit's +1 that brings us to 5 +1s (Colin, Daniel, Ed, Abhijit, and
> Alexis).
>
> We still need one more +1 for a majority.
>
> --Colin
>
>
> On Wed, Sep 7, 2016 at 7:07 PM, Abhijit Kumbhare <abhijitkoss at gmail.com>
> wrote:
>
>> My biggest concern with the vote was that we have these 4 project RGs +
>> the CALs. So my gut reaction was that for some of the RGs we had projects
>> that were shoo-ins without a real vote. Particularly since the consensus
>> seems to be forming for the project RG seats to be evenly distributed -
>> either 3 or 2 for every project RG.
>>
>> But looking at the latest ODL map (that Daniel just shared & I updated
>> based on the community feedback) - the situation does not seem so bad in
>> terms of shoo-ins. In the map, we have 7 reds (kernel), 7 purple (support),
>> 15 yellows (protocol) and 36 greens (apps). If we have 2 for each RG with 5
>> or 7 for CALs - we probably don't have shoo-ins. So the distribution is
>> roughly OK - as long as it does not vary too much from the map.
>>
>> But I guess this vote is not for the number of seats for each RG - rather
>> which groups can make up the RGs. With that in mind:
>>
>> +1
>>
>>
>> On Wed, Sep 7, 2016 at 1:10 PM, Colin Dixon <colin at colindixon.com> wrote:
>>
>>> So, I'm in no way, shape, or form trying to stop discussion if that's
>>> what people think we need, but I feel like we've been around this issue a
>>> bunch of different ways without too much recent perturbations.
>>>
>>> 1.) We've talked about all CAL and seemed to think that there's some
>>> value in balancing power between different interests.
>>> 2.) I think kernel and support have wildly different (perhaps the most
>>> opposing) interests, so lumping them together feels odd.
>>>
>>> If others feel compellingly like we haven't discussed this enough, we
>>> can keep going, but should bear in mind that we were hoping to have
>>> elections after the Boron release, which is likely happening in the next 12
>>> days.
>>>
>>> --Colin
>>>
>>>
>>> On Wed, Sep 7, 2016 at 4:06 PM, Abhijit Kumbhare <abhijitkoss at gmail.com>
>>> wrote:
>>>
>>>> I think we should discuss for 2 minutes on the call on the alternatives
>>>> we have.
>>>>
>>>> Current proposal as-is (4 project groups * 2 seats + CAL):
>>>>
>>>> * Kernel
>>>> * Protocol/Services
>>>> * App
>>>> * Support
>>>> * Committer at Large (CAL)
>>>>
>>>> Less RGs (3 project groups * 3 seats + CAL):
>>>>
>>>> * Kernel / Support
>>>> * Protocol/Services
>>>> * App
>>>> * Committer at Large (CAL)
>>>>
>>>> All CALs?
>>>>
>>>> Anything else?
>>>>
>>>>
>>>> On Wed, Sep 7, 2016 at 12:57 PM, Colin Dixon <colin at colindixon.com>
>>>> wrote:
>>>>
>>>>> In general, I think it's up to projects to figure out how they see
>>>>> themselves within reason. I'm fine with defining things like
>>>>> topo-processing and genius to be either support or services.
>>>>>
>>>>> My intuition is that SFC is an app more than protocol or service, but
>>>>> I'd leave that up to them I think.
>>>>>
>>>>> --Colin
>>>>>
>>>>>
>>>>> On Wed, Sep 7, 2016 at 3:46 PM, Abhijit Kumbhare <
>>>>> abhijitkoss at gmail.com> wrote:
>>>>>
>>>>>> Can someone refresh what all are under protocol/services? Protocols
>>>>>> are clear cut: BGP, OVSDB, OpenFlow, SNMP, LISP, etc. What are the
>>>>>> services? Topo Processing, Genius? Where had we decided SFC to be - app or
>>>>>> services?
>>>>>>
>>>>>> On Wed, Sep 7, 2016 at 11:20 AM, Colin Dixon <colin at colindixon.com>
>>>>>> wrote:
>>>>>>
>>>>>>> On the Election thread here:
>>>>>>> https://lists.opendaylight.org/pipermail/tsc/2016-September/
>>>>>>> 005920.html
>>>>>>>
>>>>>>> It seems like we have consensus that the "All Types + CAL" RGs are
>>>>>>> the right set for a variety of reasons including that having lifecycle
>>>>>>> types be RGs combined with caps on the number of TSC seats held by a
>>>>>>> representatives from a given RG causes problems.
>>>>>>>
>>>>>>> So, I'd ask TSC members to agree on the having the following 5
>>>>>>> repsented groups:
>>>>>>> * Kernel
>>>>>>> * Protocol/Services
>>>>>>> * App
>>>>>>> * Support
>>>>>>> * Committer at Large (CAL)
>>>>>>>
>>>>>>> We'll have a separate vote about how many seats are assigned to each.
>>>>>>>
>>>>>>> --Colin
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> TSC mailing list
>>>>>>> TSC at lists.opendaylight.org
>>>>>>> https://lists.opendaylight.org/mailman/listinfo/tsc
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
> _______________________________________________
> TSC mailing list
> TSC at lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/tsc
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendaylight.org/pipermail/tsc/attachments/20160908/380e847c/attachment.html>


More information about the TSC mailing list