Open Stack

Dima,

A very huge +1 to the initiatives, especially Diversity, you have
listed here and a big congratulations to everyone.

Thanks,
Dims

On Thu, Nov 19, 2015 at 3:04 AM, Dmitry Borodaenko
<dborodaenko at mirantis.com> wrote:
> Fuel team,
>
> You've heard the good news. After 4 months of hard work on expanding our
> collaboration with other OpenStack projects and aligning our development
> and governance processes with the OpenStack project requirements, our
> proposal to add Fuel to OpenStack projects [0] was approved by the
> Technical Committee.
>
> [0] https://review.openstack.org/199232
>
> This is a huge achievement for Fuel, there's no doubt about that. I'd
> like to thank everyone who made this possible. Everyone who runs
> technical discussions on openstack-dev, helps our users and contributors
> on IRC, represents Fuel in community meetings, meetups, and summits,
> removes code duplication between fuel-library and puppet-openstack,
> modularizes Fuel components for better reuse outside Fuel, makes Fuel
> more distro-independent, those who covered all Fuel repositories with
> voting gate jobs -- you all know who you are. You're awesome, you made
> it happen, thank you!
>
> This is also a beginning of a much greater journey. We have convinced
> the Technical Committee that we are willing and able to operate as an
> OpenStack project. Now we get to the hard part: convince the rest of the
> community that Fuel is worth contributing to, that we can and we will
> support new contributors, that we will remain true to the OpenStack's "4
> opens": Open Source, Open Community, Open Development, Open Design.
>
> With all the technical challenges that we need to resolve, the biggest
> challenge for Fuel right now remains a social one: we need more people
> from different backgrounds, with different needs and different opinions,
> to become active participants and eventually core reviewers in Fuel
> components.
>
> How do we know when we've fixed the diversity problem? Simple: TC has
> defined a diverse-affiliation tag [1] specifically to address this. All
> we need is to make it our top priority to invite, encourage, coach, and
> promote new contributors until we satisfy this tag's requirements.
>
> [1] http://governance.openstack.org/reference/tags/team_diverse-affiliation.html
>
> I believe this will be an effort well spent. An hour spent coaching a
> new contributor who will then contribute many hours worth of effort into
> making Fuel better, more flexible and reliable, is more than worth it.
>
> The next big challenge is as much social as it is a technical one. There
> are many projects in OpenStack that can benefit greatly from
> collaboration with Fuel, and, as our experience collaborating with
> Puppet OpenStack project shows, Fuel can benefit just as much from
> collaborating with them.
>
> First of all, Infrastructure needs our help. We've just dumped a massive
> project in their lap (over 400K lines of code in more than 20 git
> repositories), we owe it to them to pull our own weight and help them
> deal with increased load of the new gate jobs we've just set up. I've
> appointed Aleksandra Fedorova and Igor Belikov as our liaisons to the
> Infrastructure team -- not just to look after our own gates, but to
> actively look for new ways to improve and integrate.
>
> The investigation of how to run Fuel's deployment tests on nodepool [2]
> must continue, and I call other Fuel developers, especially from the QA
> team, to join and start making some progress with design and
> implementation.
>
> [2] http://lists.openstack.org/pipermail/openstack-dev/2015-November/079284.html
>
> This is not just about making more Fuel compliant with OpenStack
> policies, and not just about reducing the diversity of technologies that
> Infrastructure project has to deal with. It's about enabling
> Infrastructure to support a greater range of multi-node tests across all
> OpenStack projects, and building a CI/CD based OpenStack development
> workflow around Fuel.
>
> There's more synergy opportunities all over the place. The one we've
> known about for a while and should revisit again is expanding Ironic's
> flexibility with the image based provisioning capacities of the
> fuel-agent. As we look into deploying containerized OpenStack services,
> we must work closely with the Kolla project. Making Fuel fully
> distro-independent is not going to be possible without help from the RPM
> and DEB packaging projects. I'm open for more suggestions, but I think
> the above makes a good initial list of collaboration priorities.
>
> Last but not the least, it's time to get back to the plan for aligning
> Fuel release schedule with that of OpenStack. We're still in line with
> my proposal from August [3], I think we should stick to that and work
> closely with Packaging and Puppet projects to make sure we can release
> Mitaka based Fuel 9.0 weeks (rather than months) after Mitaka itself is
> released. For the n/10.0 release, we should start thinking about
> switching completely to the OpenStack release schedule.
>
> [3] http://lists.openstack.org/pipermail/openstack-dev/2015-August/073110.html
>
> I know all this is a tall order, and between it all we still have to
> release Liberty based Fuel 8.0 on time, and keep our quality going up,
> and keep new features flowing in. I wouldn't ask you this if I didn't
> think you could do it. When I look back and consider how far Fuel has
> come since it was first released in March 2013, how much it evolved in
> terms of architecture flexibility and engineering process maturity, all
> I can think of is: we can do anything!
>
> --
> Dmitry Borodaenko
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Davanum Srinivas :: https://twitter.com/dims