[openstack-dev] [fuel] PTL Candidacy

Dmitry Borodaenko dborodaenko at mirantis.com
Mon Sep 28 20:20:29 UTC 2015

I'd like to announce my candidacy as Fuel PTL for the next cycle.

It is our very first election, so we are taking our time to make sure we
get everything right. We have extended the nomination period to
September 28 [0] to give Fuel contributors more time to learn about the
OpenStack governance process [1] and discuss how it is going to apply to
Fuel [2].

[0] https://wiki.openstack.org/wiki/Fuel/Elections_Fall_2015#Timeline
[1] https://wiki.openstack.org/wiki/Governance
[2] http://eavesdrop.openstack.org/meetings/fuel/2015/fuel.2015-09-24-16.02.log.html#l-91

Fuel is a large project with well defined component boundaries. Some of
these components are as large and as active as whole other OpenStack
projects [3]. To improve our ability to cope with code review, design
review, and dispute resolution, we're introducing a role of a Component
Lead for the two largest components, and a team structure policy [4]
that will help new contributors find the right people for each stage of
our development process: from discussing ideas to reaching consensus
about design to getting the implementation reviewed and merged.

[3] https://lwn.net/Articles/648610/
[4] https://review.openstack.org/225376

Electing a PTL is an important step towards more open governance,
development, and community collaboration. Still, it is only one step,
and while we have made significant progress this year, there is still a
lot of work to be done before we can meet all the requirements of
becoming an official OpenStack project [5].

[5] https://review.openstack.org/199232

Specifically, we need to eliminate code duplication with Puppet
OpenStack project, and bring all our git repositories in compliance with
the Project Testing Interface, before bringing our proposal to join the
Big Tent back to the attention of the Technical Committee.

I think that in the next six months we should focus on the following:

- Continue improving our collaboration with Puppet OpenStack project and
  complete the migration from local forked copies to reusing upstream
  Puppet modules with librarian-puppet-simple.

- Collaborate with other OpenStack projects, most importantly RPM and
  DEB Packaging, OpenStack Infrastructure, and Documentation.

- Implement PTI [6] for all Fuel components and get commits to all our
  repositories gated with unit tests (as well as functional and
  integration tests where possible) on OpenStack Infrastructure.

  [6] http://governance.openstack.org/reference/project-testing-interface.html

- Continue and expand modularization efforts on all levels for better
  reuse of Fuel components both internally and in other projects. Follow
  fuel-agent [7] as the first example of how to extract parts of
  fuel-web into self-sufficient sub-projects. Expand applicability of
  plugins [8], deployment tasks [9], and network templates [10] to make
  it easier to adapt Fuel for different use cases.

  [7] https://docs.mirantis.com/openstack/fuel/fuel-6.1/reference-architecture.html#fuel-agent
  [8] https://wiki.openstack.org/wiki/Fuel/Plugins
  [9] https://docs.mirantis.com/openstack/fuel/fuel-6.1/reference-architecture.html#task-based-deployment
  [10] https://blueprints.launchpad.net/fuel/+spec/templates-for-networking

- Expand Fuel developers documentation [11] and wiki [12], populate more
  of our component README files with information for contributors.
  Unsurprisingly, README.md in fuel-docs is a good example of that [13].

  [11] https://docs.fuel-infra.org/fuel-dev/
  [12] https://wiki.openstack.org/wiki/Fuel/How_to_contribute
  [13] https://github.com/stackforge/fuel-docs/blob/master/README.md

- Make our decision making process more transparent. We are already
  using fuel-specs repository [14] to discuss design specifications for
  Fuel bluprints, we should use openstack-dev and IRC more actively to
  include more people from OpenStack community in our technical

  [14] http://specs.fuel-infra.org/fuel-specs-master/

I have long advocated for more collaboration with the free software
community, and I strongly believe that paying close attention to
feedback from the community, encouraging new contributors, and building
a healthy and diverse community around Fuel is the best way to make Fuel
the awesomest OpenStack deployment tool for everyone.

[15] https://lists.launchpad.net/fuel-dev/msg00727.html

Thank you for your consideration,

Dmitry Borodaenko

More information about the OpenStack-dev mailing list