[openstack-dev] [puppet] [fuel] more collaboration request

Emilien Macchi emilien at redhat.com
Fri Jun 12 16:14:52 UTC 2015



On 06/12/2015 11:41 AM, Sergii Golovatiuk wrote:
> Hi,
> 
> I have read all this thread trying to understand what's going on. It has
> many emotions but very few logical proposals. Let me try to sum up and
> make some proposals.
> 
>     * A bug is reported in both Fuel Library and the Puppet module having
>     trouble. A patch is provided in Fuel Library (your fork of Puppet
>     OpenStack modules) but not in Puppet upstream module. That means you fix
>     the bug for Fuel, and not for Puppet OpenStack community. It does not
>     happen all the time but quite often.
> 
> 
> I agree, Fuel Library had such issues in the past. As Dmitry Borodaenko
> noted we changed the policy and follow it. Fuel Core reviewers don't
> accept the patch if it's not submitted to upstream first. Fuel Library
> does all its best to have less divergence with community.
> 
>  
> 
>     * A patch is submitted in a Puppet module and quite often does not land
>     because there is no activity, no tests or is abandonned later because
>     fixed in Fuel Library. I've noticed the patch is fixed in Fuel Library
>     though.
> 
> 
> John F. Kennedy said:  
> "Ask not what your country can do for you — ask what you can do for your
> country"
> 
> IMO, it's a communication issue and related  more to Puppet OpenStack
> community that to Fuel Library folks. In Fuel Library when patch from
> external contributor has some problems we cherry-pick it, update a
> patchset to succeed our expectations. Meanwhile we contact the
> contributor over IRC or email and explain why we did that. That's very
> important as contributor may not know all architectural details. He may
> not know the details of CI tests or details how we test. That's the good
> attitude to help newcomers. So they will be naturally involved to
> community. Yes, it takes time for Fuel Library folks, but we continue
> doing that way as we think that communication with contributor is a key
> of success.

Adding someone by using Gerrit is not enough. Communication on IRC with
Puppet OpenStack group would be good on the right channel, like it's
done in other OpenStack projects quite often.

> I have looked over patches in progress. I may be wrong but I didn't find
> that Puppet OpenStack community updated patch to pass CI. It's not
> complex to cherry-pick and fix failed tests. It's also not complex to
> contact person over IRC or in email to explain what needs to be done.
> Trust me, usually it takes once. Smart creatives are clever enough not
> to make same mistakes twice.
> 
>      RAW copy/paste between upstream modules code and your forks. In term
>     of Licensing, I'm even not sure you have the right to do that (I'm not a
>     CLA expert though) but well... in term of authorship and statistics on
>     code, I'm not sure it's fair. Using submodules with custom patches would
>     have been great to respect the authors who created the original code and
>     you could have personalize the manifests.
> 
> 
> This happens. People fork projects when they have some communication
> issues or different architectural views. However, I like Compiz and
> Beryl story. After some time both communities negotiated the issues and
> merged the projects. Merging projects and make some concession is more
> respectful in terms of attitude between smart creatives.
> 
>     We as a community don't do a great job watching bugs, so personally
>     I'd prefer that fuel developers just push patches, filing a bug too
>     if you want. (Note: we do need to improve our bug tracking!) 
> 
> 
> Thank you Matt for bringing this up. That's definitely needs
> improvement. I asked people in Fuel Library in person if they know how
> to open a bug in Puppet OpenStack community. They also said "We usually
> create a review and add someone's from community to review". Dmitry
> Borodaenko already pointed to "How To contribute" guide and policy that
> everyone in Fuel follows. It helps a lot for our external contributors.
> Also we do strictly require "Closes-Bug" or "Implements: blueprint" in
> every review.
> 
> There only few bugs on https://bugs.launchpad.net/puppet-openstack/+bugs
>  Though, there is no assignee or milestones. Some bugs can be
> invalidated. Some bugs require additional info but nobody asked to
> provide that info.

https://bugs.launchpad.net/puppet-openstack/+bugs is for
puppet-openstack, which is deprecated in Juno.

You should look https://launchpad.net/openstack-puppet-modules which
contains mostly triaged bugs.

> Velocity of review is also a big problem fur Fuel. Sometimes it takes
> 3-6 months even when all tests are written and tested. That happened
> when we worked on Juno where Fuel library submitted many patches before
> official packages were released. This should be improved also.

"This should be improved also" > sorry but we can't do magic here.
Puppet OpenStack folks is already working a lot and we do our best to
clean the upstream patches backlog.

3-6 months rarely happens and when it does, it's quite often because
nobody takes care of the patch (both from commiter & reviewer side, I
don't blame anyone).

Honestly, if you submit a good patch now, it will land in maximum one
week or so.

If Fuel team could also participate in upstream reviews that would be
awesome:
* they would be involved in the community
* they would get experience from other patches and provide better
patches in the future, and get reviews merged faster.

> 
> Going back to resolution and action items:
> 
> We as all smart creatives have own vision. As Emilien mentioned Fuel
> developers don't participate in weekly meetings or mailing lists. That's
> true :( Though we participate in summit and follow the best practices in
> code styling and test coverages. I believe that communication
> improvement may resolve such issues. If we both start involving people
> to reviews and talk personally over IRC that will be a bit win for both
> projects. I believe we'll have synergy so there will be no divergence.

+1, like I said in another reply, communication would be a good start.
Participating to upstream's life (reviews, meetings, ML) would be also
another good thing.

> Fuel as well as other projects like TripleO will use upstream manifests
> from master without any modifications. The developers will work on
> enhancement functionality speeding up the development process.

TripleO already does FYI.

> From Fuel side I see that some engineers will be involved to review
> process. They will participate in weekly meetings. They also be active
> in communication asking people for help in review or asking why CI failed.

Good.

> From Community side there will be more active steps in review,
> communication, allowing Fuel library to participate in architectural
> voting and decision making process and be core reviewers eventually. 
> 

That is awesome, I'm really happy to hear that.

It sounds like we're approaching to a good consensus here.
-- 
Emilien Macchi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150612/252436f1/attachment.pgp>


More information about the OpenStack-dev mailing list