Open Stack

confirmed

On 04/15/2014 02:04 PM, Steven Hardy wrote:
> Hi all!
> 
> I'd like to announce my candidacy to serve as a TC member.
> 
> 
> About me:
> 
> I'm a software engineer at Red Hat, and have been working full-time on
> OpenStack for the last two years.  I've been heavily involved with the Heat
> project since before it was incubated, served as PTL for the Havana cycle,
> and remain one of the top contributors to the project.
> 
> During Icehouse, I've been trying to improve my knowledge and involvement
> with other projects, in particular contributing fixes to keystone and
> working to improve Heat's functional testing via tempest.
> 
> Platform:
> 
> Working on orchestration provides a unique view of OpenStack - it's
> essential to learn at least a little bit about every other project, because
> orchestration integrates with everything.  This is an exciting challenge,
> and provides a pretty broad perspective on issues such as API and client
> consistency.
> 
> I am of the opinion that OpenStack should be inclusive by default and,
> trademark considerations aside, should not be limited to a "core" of
> components.  Instead I see OpenStack developing into an increasingly
> powerful collection of abstractions, providing consistency for users and
> flexibility for deployers.  If elected I would strive to work as an
> advocate for new and recently graduated projects, seeking to identify
> common problems and opportunities for improved integration.
> 
> The issues I would consider priorities were I to be elected are detailed
> below, the common theme is basically better communication, efficiency and
> reuse:
> 
> 1. API consistency and reuse
> 
> I believe we're making great progress and improving API consistency but
> there are still challenges and opportunities, primarily around improving
> cross-project consistency, communication and reuse.  I see the TC's role
> here as primarily one of facilitating and encouraging cross-project
> discussion, providing direction and monitoring progress.
> 
> Closely related to this is encouraging projects to more pro-actively
> collaborate via cross-project initiatives such as oslo.  Ultimately we all
> benefit if we can reduce duplication of effort and collaborate on shared
> solutions.
> 
> I believe that the TC should be providing clear leadership and direction
> which encourages projects to avoid long term fragmentation as ultimately it
> harms the user community (users operators and deployers getting
> inconsistent experience) and developers (maintenance burden and lack of
> knowledge transfer between projects).
> 
> Finally client API consistency should be improved, in particular working
> towards common solutions for version discovery and common version-agnositc
> interfaces which reduce the (IME considerable) pain users experience when
> API versions change.
> 
> 2. Mentoring of new projects
> 
> Having experienced the incubation process, and subsequent rapid growth of
> the Heat project, I've got first-hand experience of the challenges
> experienced by new projects seeking to become part of OpenStack.  There is
> a lot of accumulated experience and knowledge in the community, and
> in many cases this "lore" is not documented for new projects and
> contributors.
> 
> I think the TC should strive to encourage more active mentoring of new
> projects, by implementing a scheme where a representative from the
> incubated project is paired with a person experienced with the area related
> to a graduation requirement, over time this can lead to identifying areas of
> common confusion, improved documentation, and hopefully engage new
> contributors (and reviewers) to participate in components related to gate
> integration and testing.
> 
> 3. Review of current PTL model
> 
> After serving as the Heat PTL for Havana, I was left with the (apparently
> not that uncommon) impression that there are aspects of the PTL role and
> responsibilities which are sub-optimal for a diverse open-source project.
> 
> As such, I would propose a review of the current model, where a PTL's
> primary function is release management and coordination, not really
> technical leadership in many cases.
> 
> I would encourage consideration of a move to a "subsystem maintainer"
> structure, similar to that used for the Linux kernel, where individual
> projects and project sub-components are afforded more autonomy and less
> granular management, in exchange for an increased requirement for
> participation in automated gate integration testing.
> 
> There may be other alternative solutions, but I believe it's time to
> initiate some discussion around what may be the most effective and
> appropriate strategy for project release management and leadership in an
> increasingly diverse and fast-moving environment.
> 
> Thanks for your consideration!
> 
> --
> Steve Hardy
> Red Hat Engineering, Cloud
> 
> _______________________________________________
> 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: 555 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140415/b5172ffe/attachment.pgp>