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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev