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 <[email protected]> wrote: > > On Thu, Jun 19, 2014 at 7:55 PM, Stephen Balukoff <[email protected]> > 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 <[email protected]> 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 < >>> [email protected]> >>> > 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 >>> >> [email protected] >>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >>> >> >>> > >>> > >>> > >>> > _______________________________________________ >>> > OpenStack-dev mailing list >>> > [email protected] >>> > 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 >>> [email protected] >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >> >> -- >> Stephen Balukoff >> Blue Box Group, LLC >> (800)613-4305 x807 >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
