Open Stack

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.

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.

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.


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. 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.

>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.

>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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150612/c26eb9fa/attachment.html>