Re: [openstack-dev] [Octavia] PTL and core team members
On 20/06/14 07:29 +0100, Mark McLoughlin wrote: On Thu, 2014-06-19 at 20:36 -0700, Dustin Lundquist wrote: Dolph, I appreciate the suggestion. In the mean time how does the review process work without core developers to approve gerrit submissions? If you're just getting started, have a small number (possibly just 1 to begin with) of developers collaborate closely, with the minimum possible process and then use that list of developers as your core review team when you gradually start adopting some process. Aim to get from zero to bootstrapped with that core team in a small number of weeks at most. Minimum possible process could mean a git repo anywhere that those initial developers have direct push access to. You could use stackforge from the beginning and the developers just approve their own changes, but that's a bit annoying. +1 this is how we did it in Marconi (except for the repo with push access). At the beginning, we kept a core team of 2 developers despite there being at least 4 ppl working on the project. This allowed the team to have better discussions on what got in the repo and what not. One benefit of using stackforge is that you get a great CI system to test your project with but the development will slow down for sure. We started on stackforge right away, then had a 2 days hackathon on a github fork which was not a good idea because we had to submit al those patches for review after the hackathon. :( Flavio -- @flaper87 Flavio Percoco pgp3yPPKqEift.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Octavia] PTL and core team members
I'm thinking we are going to need more than 2 on the core team at first but it is hard to tell exactly how many people will be contributing code at first. I know we've got a lot of interested parties and the possibility that some 10+ people are actively contributing. Of course, these things can only be predicted and will be unknown until it is actually known. Also, we really need to have a good plan of action. Once we get a consensus on the design we should start breaking the implementation up into umbrella blueprint specs (or epic blueprint specs) with each one detailing the bigger picture and breaking up the bigger picture into smaller tasks/stories that can be accomplished. Then people can start choosing which they would like to implement. Sounds good in theory, but actually executing it will be the tough part. Thanks, Brandon On Sun, 2014-06-22 at 13:42 +0200, Flavio Percoco wrote: On 20/06/14 07:29 +0100, Mark McLoughlin wrote: On Thu, 2014-06-19 at 20:36 -0700, Dustin Lundquist wrote: Dolph, I appreciate the suggestion. In the mean time how does the review process work without core developers to approve gerrit submissions? If you're just getting started, have a small number (possibly just 1 to begin with) of developers collaborate closely, with the minimum possible process and then use that list of developers as your core review team when you gradually start adopting some process. Aim to get from zero to bootstrapped with that core team in a small number of weeks at most. Minimum possible process could mean a git repo anywhere that those initial developers have direct push access to. You could use stackforge from the beginning and the developers just approve their own changes, but that's a bit annoying. +1 this is how we did it in Marconi (except for the repo with push access). At the beginning, we kept a core team of 2 developers despite there being at least 4 ppl working on the project. This allowed the team to have better discussions on what got in the repo and what not. One benefit of using stackforge is that you get a great CI system to test your project with but the development will slow down for sure. We started on stackforge right away, then had a 2 days hackathon on a github fork which was not a good idea because we had to submit al those patches for review after the hackathon. :( Flavio ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Octavia] PTL and core team members
Hi Brandon, Yep, that sounds like a good way to approach this. And FWIW, this week I'm planning on moving several of the designs I've presented to the group into blueprints / gerrit specs for the project and otherwise start working on a roadmap to actually get the thing built. In the mean time, there's still a ton that needs to be done on the Neutron LBaaS side of things to make sure we get feature improvements and cleaner Neutron API interfaces in before the Juno freeze. So I don't think there's a reason anyone should be idle working on these two projects, eh. Stephen On Sun, Jun 22, 2014 at 11:38 AM, Brandon Logan brandon.lo...@rackspace.com wrote: I'm thinking we are going to need more than 2 on the core team at first but it is hard to tell exactly how many people will be contributing code at first. I know we've got a lot of interested parties and the possibility that some 10+ people are actively contributing. Of course, these things can only be predicted and will be unknown until it is actually known. Also, we really need to have a good plan of action. Once we get a consensus on the design we should start breaking the implementation up into umbrella blueprint specs (or epic blueprint specs) with each one detailing the bigger picture and breaking up the bigger picture into smaller tasks/stories that can be accomplished. Then people can start choosing which they would like to implement. Sounds good in theory, but actually executing it will be the tough part. Thanks, Brandon On Sun, 2014-06-22 at 13:42 +0200, Flavio Percoco wrote: On 20/06/14 07:29 +0100, Mark McLoughlin wrote: On Thu, 2014-06-19 at 20:36 -0700, Dustin Lundquist wrote: Dolph, I appreciate the suggestion. In the mean time how does the review process work without core developers to approve gerrit submissions? If you're just getting started, have a small number (possibly just 1 to begin with) of developers collaborate closely, with the minimum possible process and then use that list of developers as your core review team when you gradually start adopting some process. Aim to get from zero to bootstrapped with that core team in a small number of weeks at most. Minimum possible process could mean a git repo anywhere that those initial developers have direct push access to. You could use stackforge from the beginning and the developers just approve their own changes, but that's a bit annoying. +1 this is how we did it in Marconi (except for the repo with push access). At the beginning, we kept a core team of 2 developers despite there being at least 4 ppl working on the project. This allowed the team to have better discussions on what got in the repo and what not. One benefit of using stackforge is that you get a great CI system to test your project with but the development will slow down for sure. We started on stackforge right away, then had a 2 days hackathon on a github fork which was not a good idea because we had to submit al those patches for review after the hackathon. :( Flavio ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Octavia] PTL and core team members
On Thu, 2014-06-19 at 20:36 -0700, Dustin Lundquist wrote: Dolph, I appreciate the suggestion. In the mean time how does the review process work without core developers to approve gerrit submissions? If you're just getting started, have a small number (possibly just 1 to begin with) of developers collaborate closely, with the minimum possible process and then use that list of developers as your core review team when you gradually start adopting some process. Aim to get from zero to bootstrapped with that core team in a small number of weeks at most. Minimum possible process could mean a git repo anywhere that those initial developers have direct push access to. You could use stackforge from the beginning and the developers just approve their own changes, but that's a bit annoying. Mark. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Octavia] PTL and core team members
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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Octavia] PTL and core team members
I'd like to nominate Brandon Logan and Doug Wiegley as core members. On Thu, Jun 19, 2014 at 6:18 PM, Stephen Balukoff sbaluk...@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Octavia] PTL and core team members
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 sbaluk...@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Octavia] PTL and core team members
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? Thanks, Stephen On Thu, Jun 19, 2014 at 3:37 PM, Anita Kuno ante...@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 sbaluk...@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@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@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Octavia] PTL and core team members
Hi y'all! So, scanning through my e-mail archives, list of people active on the ML talking about Neutron LBaaS and the load balancer side project (ie. before we started calling it octavia), people who attended the Neutron LBaaS mid-cycle hackathon (in person or remotely), people recently contributing to Neutron LBaaS related code or specs, people I recognize being active in the IRC meetings, etc. I come up with the following list. Apologies in advance for anyone I've forgotten here; errors are entirely my fault: Avishay Balderman Susanne Balle Stephen Balukoff Samuel Bercovici Vijay Bhamidipati Tom Creighton German Eichberger Evgeny Fedoruk Carlos Garza Adam Harwell Vivek Jain Miguel Lavalle Brandon Logan Dustin Lundquist Mark McClain Kyle Mestery Jorge Miramontes Eugene Nikanorov Anand Palanisamy Phil Toohill Craig Tracey Trevor Vardeman Vijay Venkatachalam Min Wang Doug Wiegley I'm thinking the people who should be involved in this election should have shown both an interest in LBaaS or the Octavia side project, and have interest and intent to contribute to this project in meaningful ways in the near future. What do y'all think of these criteria? If y'all agree to this criteria, then the next steps / questions are: 1. Who should be added to the above list who isn't on it yet (and how have they shown their interest in LBaaS or Octavia in the recent past)? 2. Who on the above list doesn't want to be on it (ie. won't be contributing to Octavia)? 3. Do we have any volunteers to run the election? (The person running the election should not be a candidate, and should, if at all possible, have no interests one way or another in Octavia.) Thanks, Stephen On Thu, Jun 19, 2014 at 6:33 PM, Anita Kuno ante...@anteaya.info wrote: On 06/19/2014 09:13 PM, Stephen Balukoff wrote: Also, to clarify: It's obviously up to Doug to determine whether he thinks contributing to Octavia would be a conflict of interest. I was just saying I wouldn't be surprised or offended if he decided to opt out because of this, eh. On Thu, Jun 19, 2014 at 5:55 PM, Stephen Balukoff sbaluk...@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? Thanks, Stephen Yes, the links were meant as a starting point for the Octivia group to decide what rules to use to conduct their election. Deciding the electorate is an important discussion to have. Once the group has decided what rules to be bound by and selected an election official, then you are ready to begin your election process. May it go well, Anita. On Thu, Jun 19, 2014 at 3:37 PM, Anita Kuno ante...@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 sbaluk...@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
Re: [openstack-dev] [Octavia] PTL and core team members
On Thu, Jun 19, 2014 at 7:55 PM, Stephen Balukoff sbaluk...@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 ante...@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 sbaluk...@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@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@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
Re: [openstack-dev] [Octavia] PTL and core team members
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.math...@gmail.com wrote: On Thu, Jun 19, 2014 at 7:55 PM, Stephen Balukoff sbaluk...@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 ante...@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 sbaluk...@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@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
