Open Stack

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 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 needs of public and private clouds
> regardless of size, by being simple to implement and massively
> scalable." (http://www.openstack.org/blog/2010/07/introducing-openstack/)
> 
> I honestly feel like we're only doing an sort of OK job right now. I
> think that the current growth of services and they way we implement them
> (by bringing in a lot of new external dependencies) is not holding true
> to "being simple to implement". I think that's excluding the use of
> OpenStack at smaller institutions. If OpenStack is only in the toolchest
> for large sophisticated institutions, it will not become ubiquitous.
> 
> Linux was deployed in production first by small ISPs, entities with only
> a few employees. If OpenStack can only be deployed by having a very
> skill integrator come on board, it by definition can't be Ubiquitous.
> 
> My feelings around a smaller nucleus/layer/ring/zone/integrated release
> are largely shaped by my feeling that we're losing the smaller users of
> OpenStack. And that's something we can fix.
> 
> == How do you feel the technical committee is doing in meeting the
> technical committee mission? ==
> 
> The mission: The Technical Committee ("TC") is tasked with providing the
> technical leadership for OpenStack as a whole (all official programs, as
> defined below). It enforces OpenStack ideals (Openness, Transparency,
> Commonality, Integration, Quality...), decides on issues affecting
> multiple programs, forms an ultimate appeals board for technical
> decisions, and generally has oversight over all the OpenStack project.
> (https://wiki.openstack.org/wiki/Governance/Foundation/TechnicalCommittee)
> 
> In the current TC, I'm one of the newest OpenStack community members. I
> was honestly surprised with how much TC time was spent evaluating new
> project requests (and this is growing over time). I think the TC mission
> for providing technical leadership and even understanding issues
> affecting multiple programs becomes very strained when the scope of that
> governance includes the whole OpenStack ecosystem. And I think it will
> limit the TC's effectiveness at having oversight when it is so far removed.
> 
> == How would you characterize the various facets of contributor
> motivation? ==
> 
> I'm not really sure the intent of this question, but I'll take a swing
> at what the author might have intended. A very large amount of OpenStack
> work today is sponsored. Some of it is very vendor oriented for very
> specific features those vendors want in the OpenStack changelogs, some
> of it is people that love this community, and have found entities that
> will support that. The fact that a huge number of our community leaders
> are not working at the same company as when they started with OpenStack
> (including myself) speaks to that passion.
> 
> I'd honestly like to see more small contributors, and more people
> feeling like they could make an impact to OpenStack even if the don't
> have the privilege to work on it full time.
> 
> == There is no argument the OpenStack technical community has a
> substantial rate of growth. What are some of the consequences of this
> rate? ==
> 
> The rate of growth has very much meant that most contributors to
> projects only contribute to their one effort. The cultures in each
> project have grown quite different over time as to what's acceptable
> patch culture for each project, acceptable review culture, how bugs get
> handled, what's validated, and many more things.
> 
> When I joined the projects one of the mantras for no non python
> OpenStack projects was that common language and common tooling would
> mean that developers and operators would have an easy time moving from
> one project to another to address an issue.
> 
> I think the explosive growth we've seen, and the challenges with
> coherent integration of all these moving parts, has shown that there is
> a lot more to unified experience than common language and tooling.
> 
> I think it has also very concretely strained the Horizontal efforts past
> their capacity points. Docs, QA, Stable Maint, Security, all very much
> have to now pick their battles and leave a lot on the cutting room floor.
> 
> Take this example: I recently started working on the final Nova fixes
> for a cross project security issue that was made public 14 months ago -
> https://bugs.launchpad.net/keystone/+bug/1188189. It's honestly unclear
> if this has been completely addressed in other projects.
> 
> == How would you characterize the experience new contributors have
> currently? ==
> 
> Terribad.
> 
> 24 steps of CLA madness, multiple ids, signing stuff,  to get to the
> point of submitting your first bug fix is insane.
> 
> You have exactly one chance to make a first impression, and today I
> think the process of contributing to OpenStack prior to even uploading
> to Gerrit is onerous enough that we're preventing most of our best
> future OpenStack contributors from ever existing.
> 
> This needs to change.
> 
> == How would you describe our current state of communication in the
> OpenStack  community? ==
> 
> I'm going to take "our" to mean all of us in the OpenStack community.
> And the best way I can say is fragmented. We have the mailing list, but
> with so many efforts being on list (Nova and Fuel being in the same
> list, for instance) it means that many things get lost. We have a vast
> array of per project IRC channels... though very little traffic on
> #openstack-dev. As far as I can tell only a very few core developers
> currently monitor #openstack-dev for interesting content, which adds
> huge burden to any cross project effort that's not got a dedicated cross
> project channel.
> 
> == The technical committee interacts with the foundation board on
> several different fronts. How would you describe these interactions? ==
> 
> Confused? No, I mean I'm confused, because honestly there seems to be
> not that many fronts in which they interact. I was very mixed on DefCore
> because it seemed like so much of the important work there happened in
> face to face meetings in San Fran. And there kept being real confusion
> over intent.
> 
> Beyond that I feel like there hasn't been a ton of Board / TC
> interaction. The joint Atlanta meetup was good, and I think some
> concerns that got raised in the room did get talked about. But I feel
> like there are actually quite different scopes of the Board trying to
> define the commercial ecosystem and market dynamics, and the TC trying
> to define a set of bits that do a thing. And hopefully keep doing that
> thing even when some more bits are added.
> Honestly, perhaps the disconnects that currently exist between the TC
> and the Board are largely around the fact that the only place our roles
> seem to overlap is near the trademark definition, and so vastly
> different perspectives exist based on the day to day challenges each face.
> 
> = Final thoughts - caveats =
> 
> I'll pre-apologize for any oddities in this write up, or if I missed
> context on questions that might have been surfaced on the mailing list.
> Or if people have noticed me absent in any community threads in the past
> week in which they expected to hear my voice (I have not read any email
> related to the project since Oct 3rd). I'm currently functioning under a
> bit of sleep deprevation after the arrival of our latest family member -
> https://twitter.com/sdague/status/519173169643388929, and will be
> disconnected from the community for the next couple weeks as I focus on
> family. I only broke the sabbatical because TC candidacy had an
> expiration date.
> 
> Will be back roaring and raring to go by Paris. And will look forward to
> seeing you all there whether or not you want me back on the TC for
> another year. :)
> 
> 	-Sean
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141009/8c4c2b3c/attachment.pgp>