Open Stack

Dolph,

I appreciate the suggestion. In the mean time how does the review process
work without core developers to approve gerrit submissions?

Thanks,


Dustin Lundquist


On Thu, Jun 19, 2014 at 8:06 PM, Dolph Mathews <dolph.mathews at gmail.com>
wrote:

>
> On Thu, Jun 19, 2014 at 7:55 PM, Stephen Balukoff <sbalukoff at bluebox.net>
> wrote:
>
>> Thanks for the link, Anita!
>>
>>  These are definitely good guidelines, but there are a couple problems
>> with doing the election exactly as described in the document:  It looks
>> like to generate the list of voters, it recommends using the list of people
>> who have committed code to the project in the last year. As this project is
>> just getting bootstrapped, obviously we have no committed code yet.
>>
>> It might be possible to use mailing list activity (in [Neutron][LBaaS] in
>> particular) to generate this list, but also keep in mind that not everyone
>> who has been active on the mailing list is interested in contributing to
>> Octavia. For example, while Doug Wiegley has made great contributions to
>> Neutron LBaaS, it's probably a conflict of interest for him to participate
>> in Octavia, since he works for a load balancer vendor.
>>
>> I do agree that the election should not be conducted by one of the
>> candidates in any case. What do y'all think, as far as determining the list
>> of who should be able to vote and/or nominate candidates?
>>
>>
> I'm going to jump in here and suggest that you slow down. Using an awful
> horse and cart analogy, it seems you're trying to select the best
> cart-pulling horse when there's not yet a cart.
>
> I'd suggest running through a development cycle without an election or an
> official PTL. **Work as a tight community of contributors to establish the
> project,** and by the time you have a real need for a PTL (probably around
> the time you begin dealing with release overhead), you'll have a list of
> eligible voters (per the election guidelines that Anita linked). More
> importantly, those voters will have developed the necessary perspective to
> go about nominating and voting for a PTL with confidence.
>
> Best of luck!
>
> -Dolph
>
>
>> Thanks,
>> Stephen
>>
>>
>>
>> On Thu, Jun 19, 2014 at 3:37 PM, Anita Kuno <anteaya at anteaya.info> wrote:
>>
>>> On 06/19/2014 06:29 PM, Craig Tracey wrote:
>>> > I'd like to nominate Brandon Logan and Doug Wiegley as core members.
>>> >
>>> >
>>> > On Thu, Jun 19, 2014 at 6:18 PM, Stephen Balukoff <
>>> sbalukoff at bluebox.net>
>>> > wrote:
>>> >
>>> >> Howdy y'all!
>>> >>
>>> >> Among other things that happened at the Neutron LBaaS mid-cycle
>>> hackathon,
>>> >> we have now put together process around, and established Octavia as a
>>> >> stackforge project. For those just joining us, Octavia is going to
>>> become
>>> >> an open-source operator-grade load balancer implementation. It will
>>> consume
>>> >> the Neutron LBaaS driver API, and be a consumer of Neutron, Nova, and
>>> other
>>> >> OpenStack APIs to deliver load balancing services. (It is not meant to
>>> >> supplant Neutron LBaaS, or be a general solution which can work with
>>> any
>>> >> vendor back-end. Think of it as another load balancer vendor.)
>>> >>
>>> >> Anyway, since we want to run this project with the intent of
>>> eventually
>>> >> being incubated, we'd like to get it off the ground using standard
>>> >> OpenStack methodologies, processes, and best practices. This also
>>> means
>>> >> that we need a PTL and team of core developers who will have +2 voting
>>> >> status on code and spec reviews for the project.
>>> >>
>>> >> I'd like to throw my hat into the ring for PTL.
>>> >>
>>> >> I'm not sure how elections on this should work (other than being
>>> open).
>>> >> But in any case, I also think that core developers for this project
>>> should
>>> >> probably come from the companies who have been active in the
>>> discussion of
>>> >> LBaaS in the last few months who are also interested in contributing
>>> to the
>>> >> Octavia project.
>>> >>
>>> >> Who would you like to see as PTL and core developers in this project?
>>> >>
>>> >> Thanks,
>>> >> Stephen
>>> >>
>>> >>
>>> >> --
>>> >> Stephen Balukoff
>>> >> Blue Box Group, Inc.
>>> >> (800)613-4305 x807
>>> >>
>>> >> _______________________________________________
>>> >> OpenStack-dev mailing list
>>> >> OpenStack-dev at lists.openstack.org
>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >>
>>> >>
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > OpenStack-dev mailing list
>>> > OpenStack-dev at lists.openstack.org
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>> Technical Governance in OpenStack:
>>> https://wiki.openstack.org/wiki/Governance
>>>
>>> Guidelines for Election Officials:
>>> https://wiki.openstack.org/wiki/Election_Officiating_Guidelines
>>>
>>> I recommend asking or designating someone to act as an election official
>>> for the election. OpenStack elections need two officials, Stackforge
>>> elections often have one, though you can have two if you wish. Establish
>>> which processes you as a group will follow for the election. Part of the
>>> election official's job is to open nominations.
>>>
>>> Congratulations on the new Stackforge project, may you have a good
>>> election process,
>>> Anita.
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
>> --
>> Stephen Balukoff
>> Blue Box Group, LLC
>> (800)613-4305 x807
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140619/72ecd04f/attachment.html>