Open Stack

confirmed

On 08/10/14 05:51 AM, Eoghan Glynn wrote:
> 
> 
> Folks,
> 
> I would like to throw my hat into the ring for the upcoming Technical
> Committee election.
> 
> I've been involved in the OpenStack community for nearly three years,
> starting off by becoming core on glance, before moving my focus mainly
> onto the ceilometer project. Along the way I've landed a smattering of
> commits across nova, heat, cinder, horizon, neutron, oslo, devstack,
> and openstack-manuals, while contributing to the stable-maint effort
> over multiple cycles.
> 
> More recently, I've served the ceilometer project as PTL over the Juno
> cycle, and will be doing so again for Kilo.
> 
> I'm employed by Red Hat to work primarily upstream, but I also have
> some perspective on the "sausage machine" that operates downstream in
> order to put the technology we produce into the hands of users.
> 
> My motivation in running is to bring more perspective from a smaller
> project to the deliberations of the TC, which I think already has a
> tonne of large-project and cross-project perspective to draw on.
> Balance is a good and healthy thing :)
> 
> As a community we have a big challenge ahead of us to figure out how
> we respond to the growing pains that been felt in our governance
> structure and cross-project resources. This has crystallized around
> the recent layering and big tent discussions. My own feeling has
> always been in favor of a big welcoming tent, but I'm less convinced
> that a small blessed core is necessarily a corollary of such
> inclusiveness. Before we radically alter the release cycle model
> that's served us relatively well thus far, I think a critical eye
> should be brought to the proposals; in particular we really need to
> clearly identify the core problems that these proposed changes are
> intended to solve.
> 
> And so, onwards to the stock questions ...
> 
> Topic: OpenStack Mission
> ========================
> 
> How do you feel the technical community is doing in meeting the
> OpenStack Mission?
> 
> In all honesty, I would give us an A+ for effort, but more like a B-
> for execution. In our excitement and enthusiasm to add shiny new
> features, we sometimes take our eye off the ball in terms of what's
> needed to make the lives of our users easier. I'm as guilty of this as
> anyone else, perhaps even more so. But I think at this stage, it would
> be of much benefit to our user community if we swung the pendulum
> somewhat in the other direction, and shifted some focus onto easing
> the practical challenges of operating our stuff at scale.
> 
> Topic: Technical Committee Mission
> ==================================
> 
> How do you feel the technical committee is doing in meeting the
> technical committee mission?
> 
> Well, to be honest, if I thought this couldn't be improved, I wouldn't
> be running for election.
> 
> On the one hand, I felt the gap analysis for already-integrated
> projects was a good and healthy thing, and certainly assisted in
> focusing resources over Juno on the areas where the TC saw
> deficiencies.
> 
> On the other hand, I was quite disheartened by how some of the TC
> discussions around project status played out. IMO there was a failure
> of due diligence and mentoring. If we continue to have the TC making
> important determinations about the future of projects (whether it be
> their integrated status or their "production readiness"), then I think
> we need to ensure that the TC keeps itself fully appraised from an
> earlier stage about the direction that the project is taking, and
> gives fair warning when it feels that a project needs a
> course-correction.
> 
> Topic: Contributor Motivation
> =============================
> 
> How would you characterize the various facets of contributor
> motivation?
> 
> Most of my prior opensource experience was on various Apache projects
> and in contrast it's striking that the OpenStack contributor community
> is on the whole more skewed away from pure volunteerism, and towards
> corporate contributors. By that, I mean contributors who are employed
> by major operators and distributors of OpenStack, where their day-job
> is to go forth and make it better. On balance, this is actually a
> strength in our community. It certainly aids in the continuity and
> sustainability of effort. It also helps ensure that less glamorous,
> but ultra-important, efforts such as stable-maint and vulnerability
> management get the attention they deserve.
> 
> However, despite this skew, I'm well aware that we're building a
> "broad church" here. I think we all benefit from active efforts to
> build diversity in our contributor community and harness the energy of
> contributors with all kinds of motivations. Not just because it's the
> right-on thing to do, but because it's the *smart* thing to do
> ... ensuring that we get access to all of the talents, especially from
> previously under-represented groups. Towards this end, I continue to
> support the efforts of programs such as the GNOME OPW and their recent
> moves towards extending their reach to a wider set of contributor
> backgrounds.
> 
> Topic: Rate of Growth
> =====================
> 
> There is no argument the OpenStack technical community has a
> substantial rate of growth. What are some of the consequences of this
> rate?
> 
> It's clear that we're nearing an inflection point in our growth path,
> where the ability of our cross-project concerns to continue scaling up
> to meet the growing demand can no longer be taken for granted.
> 
> My instinct on this is to first examine how we organize those
> cross-project concerns to see if the scalability ceilings can be
> raised, before going down the route of rationing these cross-project
> resources across a smaller set of projects.
> 
> Topic: New Contributor Experience
> =================================
> 
> How would you characterize the experience new contributors have
> currently?
> 
> To answer this question, I tried to project myself back to my own
> journey up the on-ramp. It was of course a simpler time in terms of
> the proliferation of projects and services, but the key elements have
> mostly remained the same. 
> 
> Firstly, the good ...
> 
> One thing I found awesomely useful at the time was the ability to
> easily spin up an entire mini-cloud in a VM and just get my hands
> dirty, attempt to decipher the logs, snoop the messages passing
> between services, peek inside the databases and so on. Given that we
> rely on it so heavily in our day-to-day, it's easy to forget how
> helpful devstack really is. I found it a massive leg-up, coming from a
> scenario where setting up any kind of simulacrum of production was
> quite a gnarly task.
> 
> I also found refreshing the willingness of various "old-timers" to
> answer my dumb noob questions in a friendly and non-judgemental way.
> We should never under-value this quality in our community, anyone who
> in a past life has struggled with knowledge-hoarding will attest to
> how open we are in this respect.
> 
> Next, the bad ...
> 
> We have a particular culture on gerrit were newbies sometimes feel
> they're being ignored, or at least that their patches are not getting
> the timely traction they expect. I know I fell into this trap myself
> back in the day, where I followed up a git push with an almost
> immediate full-court-press on potential reviewers via IRC. With
> predictably counter-productive results. I think we could better
> serve new contributors by setting more realistic expectations of
> review turnaround from the very outset.
> 
> And finally, the ugly ... ;)
> 
> Ah yes, the old Contributor License Agreement that many of us love to
> hate. TBH being required to sign this was more of an irritation to me
> when I first encountered it, but thanks to efforts over the last
> couple of cycles by some individuals on the TC, I now have a much
> clearer perspective on the real and practical difficulties this
> seemingly unnecessary legalism introduces for some contributors.
> Needless to relate, I'd be fully supportive of the TC's continuing
> efforts to replace the CLA with the Developer Certificate of Origin.
> 
> Topic: Communication
> ====================
> 
> How would you describe our current state of communication in the
> OpenStack community?
> 
> We have many "official" vectors of communication: the design summit,
> mailing lists, mid-cycle meetups, gerrit, logged IRC meetings and so
> on. All of these have their strenghts and weaknesses, but as a
> community we're learning to use and filter them quite well, despite
> their firehose-like nature.
> 
> There is also an emerging trend for important discussions to be
> initiated and developed outside of these official channels, e.g. via
> ad-hoc discussions and blog posts. This is something I'm not so
> enthused about, as it's harder for such channels to host a two-way
> inclusive conversation.
> 
> Also, as in any technical community that I've ever experienced,
> there's a lot of shared "tribal knowledge" sitting in peoples'
> heads. I'm as guilty of it as anyone else, perhaps even more
> so. That's just what happens day-to-day as the rate of knowledge
> accretion surpasses the time available to codify it. However we all
> need to try forcing ourselves to take the time to write such nuggets
> down in a discoverable place, in order to provide a bread-crumb trail
> for those who come behind us.
> 
> Topic: Relationship with the Foundation Board
> =============================================
> 
> The technical committee interacts with the foundation board on several
> different fronts. How would you describe these interactions?
> 
> Interestingly, the membership of these two governance structures is
> somewhat intertwined. Obviously this presents challenges for the
> individuals involved in both, in ensuring that they can "swap hats"
> and context-switch appropriately. But it does at least ensure that the
> board is not resting in an ivory tower, insulated from the day-to-day
> technical leadership. In terms of the practical interactions that I've
> seen, I was heartened by the robust approach of the TC in making their
> preference to switch to the DCO crystal-clear and putting it up to the
> board to deal with the CLA issue once and for all.
> 
> Cheers,
> Eoghan
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 


-------------- 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/20141008/8bb8c02b/attachment.pgp>