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 <dborodae...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __________________________________________________________________________ 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