Re: [openstack-dev] OpenStack Technical Committee Nomination
confirmed. Note that we are making an exception here for a brand new parent. I'd like to remind further candidate to use the proper "TC candidacy" mail subject. On 08/10/14 09:33 PM, Sean Dague wrote: > I'd like to announce throwing my hat into the ring for the OpenStack > Technical Committee. > > = My Background on the Project = > > I've been a contributor to OpenStack since late in the Essex release. I > was the QA PTL for the Havana and Icehouse cycles. I'm a core reviewer > on QA (Devstack, Grenade, Tempest), on Nova, and on the new Project > Config repo in infra, and a host of other projects in OpenStack. I was > elected to the TC last fall as part of the first fully directed TC. > > You might also know me from the fact that I spend a lot of time on the > OpenStack gate, which really means I spend a lot of time trying to > understand why when all the OpenStack components run together, they > often break horribly, and actually try to debug and address those. I was > part of the team that built Elastic Recheck > (http://status.openstack.org/elastic-recheck/) for that effort. > > In any particular release of OpenStack I'm typically one of the largest > reviewers of code. A lot of these are help shepherding in easy fixes > that get lost in our review queues. I built things like Gerrit Dashboard > Creator (https://github.com/stackforge/gerrit-dash-creator) to make it > easier for reviewers to sift patches to make sure that good patches > don't get lost, and make reviewer's lives easier. > > And I am a strong believer that the way we grow our community is through > growing our contributors. This is one of the reasons I kicked off the > OpenStack Bootstrapping Hour > (https://wiki.openstack.org/wiki/BootstrappingHour) with Jay Pipes and > Dan Smith, to provide one avenue for this growth to happen. I think many > other are required as well, but this is one way to get us started. > > = My Views on the Future of OpenStack and the TC = > > I feel like OpenStack is at a crossroads. The original definition of the > integrated release, and horizontal teams was built around the concept of > 2 projects. It worked at 5. It was strained at 8. And I think we're now > on the very of it being completely broken. > > I think that in order for OpenStack to move forward we need to > pragmatically redefine the integrated release as the set of horizontal > components that have to be linked together to be useful. Exactly the > right unit I think is up for debate. It could be as small as Nova, > Glance, Keystone, Neutron. It might include Cinder, Designate, and / or > Oslo (I can see the case for and against any of these). Those should be > the projects that QA, Docs, and Stable Maint, Release Management, > Security Team, and the TC needs to take responsibility for. > > I think that we need to have an expansive ecosystem where projects like > Swift, Heat, Horizon, Ceilometer, Trove, Congress, Sahara, Zaqar, Rally, > Ironic, and all the other really interesting projects can flourish. I > think their inclusion in the OpenStack umbrella should be a lightweight > process that is largely a self assessment and an acceptance of certain > principles that are core to OpenStack. I think these projects should be > self responsible for their own QA, Docs, Stable Maint, Security, and > Release Management. And I think mentoring should be made available to > help them with any of these. I believe a structure similar to the User > Committee is probably most appropriate here. However we get this body, > it should have an electorate (directly or indirectly) that represents > ATCs from the broadest expanse of our ecosystem. > > I think the TC needs to evolve from a policy body, to a body that's > primarily directly responsible for the integrated release (as I defined > above). Direct responsibility means more than approving and managing gap > analysis plans. It means diving directly into project code across all > the integrated release projects at substantial regularity. It could mean > the TC inheriting +2 on the integrated projects and horizontal efforts > supporting it (like QA, Docs, and Stable Maintenance) (Note: clearly we > could only do this with a strong set of expectations and checks and > balances to prevent abuse, but it's an idea that's interesting to think > about). > > I would like to think about this as a tight integrated release plus a > large and solid ecosystem. > > These are things I'm going to push for going forward, whether or not I'm > on the TC, however I think the idea of having the TC take more ownership > of the integrated release, directly. We need an OpenStack base box set > with more full and cohesive user experience (one that doesn't require > understanding and maintaining multiple db systems), that is deployable > at everything from small colleges and institutions, to giant places like > wall street, telcos, and research institutions. And then we need to have > space to promote great expansions to OpenS
Re: [openstack-dev] OpenStack Technical Committee Nomination
confirmed. Note that we are making an exception here for a brand new parent. I'd like to remind further candidate to use the proper "TC candidacy" mail subject. On 08/10/14 09:33 PM, Sean Dague wrote: > I'd like to announce throwing my hat into the ring for the OpenStack > Technical Committee. > > = My Background on the Project = > > I've been a contributor to OpenStack since late in the Essex release. I > was the QA PTL for the Havana and Icehouse cycles. I'm a core reviewer > on QA (Devstack, Grenade, Tempest), on Nova, and on the new Project > Config repo in infra, and a host of other projects in OpenStack. I was > elected to the TC last fall as part of the first fully directed TC. > > You might also know me from the fact that I spend a lot of time on the > OpenStack gate, which really means I spend a lot of time trying to > understand why when all the OpenStack components run together, they > often break horribly, and actually try to debug and address those. I was > part of the team that built Elastic Recheck > (http://status.openstack.org/elastic-recheck/) for that effort. > > In any particular release of OpenStack I'm typically one of the largest > reviewers of code. A lot of these are help shepherding in easy fixes > that get lost in our review queues. I built things like Gerrit Dashboard > Creator (https://github.com/stackforge/gerrit-dash-creator) to make it > easier for reviewers to sift patches to make sure that good patches > don't get lost, and make reviewer's lives easier. > > And I am a strong believer that the way we grow our community is through > growing our contributors. This is one of the reasons I kicked off the > OpenStack Bootstrapping Hour > (https://wiki.openstack.org/wiki/BootstrappingHour) with Jay Pipes and > Dan Smith, to provide one avenue for this growth to happen. I think many > other are required as well, but this is one way to get us started. > > = My Views on the Future of OpenStack and the TC = > > I feel like OpenStack is at a crossroads. The original definition of the > integrated release, and horizontal teams was built around the concept of > 2 projects. It worked at 5. It was strained at 8. And I think we're now > on the very of it being completely broken. > > I think that in order for OpenStack to move forward we need to > pragmatically redefine the integrated release as the set of horizontal > components that have to be linked together to be useful. Exactly the > right unit I think is up for debate. It could be as small as Nova, > Glance, Keystone, Neutron. It might include Cinder, Designate, and / or > Oslo (I can see the case for and against any of these). Those should be > the projects that QA, Docs, and Stable Maint, Release Management, > Security Team, and the TC needs to take responsibility for. > > I think that we need to have an expansive ecosystem where projects like > Swift, Heat, Horizon, Ceilometer, Trove, Congress, Sahara, Zaqar, Rally, > Ironic, and all the other really interesting projects can flourish. I > think their inclusion in the OpenStack umbrella should be a lightweight > process that is largely a self assessment and an acceptance of certain > principles that are core to OpenStack. I think these projects should be > self responsible for their own QA, Docs, Stable Maint, Security, and > Release Management. And I think mentoring should be made available to > help them with any of these. I believe a structure similar to the User > Committee is probably most appropriate here. However we get this body, > it should have an electorate (directly or indirectly) that represents > ATCs from the broadest expanse of our ecosystem. > > I think the TC needs to evolve from a policy body, to a body that's > primarily directly responsible for the integrated release (as I defined > above). Direct responsibility means more than approving and managing gap > analysis plans. It means diving directly into project code across all > the integrated release projects at substantial regularity. It could mean > the TC inheriting +2 on the integrated projects and horizontal efforts > supporting it (like QA, Docs, and Stable Maintenance) (Note: clearly we > could only do this with a strong set of expectations and checks and > balances to prevent abuse, but it's an idea that's interesting to think > about). > > I would like to think about this as a tight integrated release plus a > large and solid ecosystem. > > These are things I'm going to push for going forward, whether or not I'm > on the TC, however I think the idea of having the TC take more ownership > of the integrated release, directly. We need an OpenStack base box set > with more full and cohesive user experience (one that doesn't require > understanding and maintaining multiple db systems), that is deployable > at everything from small colleges and institutions, to giant places like > wall street, telcos, and research institutions. And then we need to have > space to promote great expansions to OpenS
[openstack-dev] OpenStack Technical Committee Nomination
I'd like to announce throwing my hat into the ring for the OpenStack Technical Committee. = My Background on the Project = I've been a contributor to OpenStack since late in the Essex release. I was the QA PTL for the Havana and Icehouse cycles. I'm a core reviewer on QA (Devstack, Grenade, Tempest), on Nova, and on the new Project Config repo in infra, and a host of other projects in OpenStack. I was elected to the TC last fall as part of the first fully directed TC. You might also know me from the fact that I spend a lot of time on the OpenStack gate, which really means I spend a lot of time trying to understand why when all the OpenStack components run together, they often break horribly, and actually try to debug and address those. I was part of the team that built Elastic Recheck (http://status.openstack.org/elastic-recheck/) for that effort. In any particular release of OpenStack I'm typically one of the largest reviewers of code. A lot of these are help shepherding in easy fixes that get lost in our review queues. I built things like Gerrit Dashboard Creator (https://github.com/stackforge/gerrit-dash-creator) to make it easier for reviewers to sift patches to make sure that good patches don't get lost, and make reviewer's lives easier. And I am a strong believer that the way we grow our community is through growing our contributors. This is one of the reasons I kicked off the OpenStack Bootstrapping Hour (https://wiki.openstack.org/wiki/BootstrappingHour) with Jay Pipes and Dan Smith, to provide one avenue for this growth to happen. I think many other are required as well, but this is one way to get us started. = My Views on the Future of OpenStack and the TC = I feel like OpenStack is at a crossroads. The original definition of the integrated release, and horizontal teams was built around the concept of 2 projects. It worked at 5. It was strained at 8. And I think we're now on the very of it being completely broken. I think that in order for OpenStack to move forward we need to pragmatically redefine the integrated release as the set of horizontal components that have to be linked together to be useful. Exactly the right unit I think is up for debate. It could be as small as Nova, Glance, Keystone, Neutron. It might include Cinder, Designate, and / or Oslo (I can see the case for and against any of these). Those should be the projects that QA, Docs, and Stable Maint, Release Management, Security Team, and the TC needs to take responsibility for. I think that we need to have an expansive ecosystem where projects like Swift, Heat, Horizon, Ceilometer, Trove, Congress, Sahara, Zaqar, Rally, Ironic, and all the other really interesting projects can flourish. I think their inclusion in the OpenStack umbrella should be a lightweight process that is largely a self assessment and an acceptance of certain principles that are core to OpenStack. I think these projects should be self responsible for their own QA, Docs, Stable Maint, Security, and Release Management. And I think mentoring should be made available to help them with any of these. I believe a structure similar to the User Committee is probably most appropriate here. However we get this body, it should have an electorate (directly or indirectly) that represents ATCs from the broadest expanse of our ecosystem. I think the TC needs to evolve from a policy body, to a body that's primarily directly responsible for the integrated release (as I defined above). Direct responsibility means more than approving and managing gap analysis plans. It means diving directly into project code across all the integrated release projects at substantial regularity. It could mean the TC inheriting +2 on the integrated projects and horizontal efforts supporting it (like QA, Docs, and Stable Maintenance) (Note: clearly we could only do this with a strong set of expectations and checks and balances to prevent abuse, but it's an idea that's interesting to think about). I would like to think about this as a tight integrated release plus a large and solid ecosystem. These are things I'm going to push for going forward, whether or not I'm on the TC, however I think the idea of having the TC take more ownership of the integrated release, directly. We need an OpenStack base box set with more full and cohesive user experience (one that doesn't require understanding and maintaining multiple db systems), that is deployable at everything from small colleges and institutions, to giant places like wall street, telcos, and research institutions. And then we need to have space to promote great expansions to OpenStack the institutions can deploy as needed for their needs that a much freer to use exciting new technology to solve interesting problems. = Standard TC Questions = == How do you feel the technical community is doing in meeting the OpenStack Mission? == Our mission statement is: "To produce the ubiquitous OpenSource Cloud Computing platform that will meet the need
