<div dir="ltr"><div>Hi,</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:13px">* A bug is reported in both Fuel Library and the Puppet module having<br></span><span style="font-size:13px">trouble. A patch is provided in Fuel Library (your fork of Puppet<br></span><span style="font-size:13px">OpenStack modules) but not in Puppet upstream module. That means you fix<br></span><span style="font-size:13px">the bug for Fuel, and not for Puppet OpenStack community. It does not<br></span><span style="font-size:13px">happen all the time but quite often.</span></blockquote><div><br></div><div>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.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:13px">* A patch is submitted in a Puppet module and quite often does not land<br></span><span style="font-size:13px">because there is no activity, no tests or is abandonned later because<br></span><span style="font-size:13px">fixed in Fuel Library. I've noticed the patch is fixed in Fuel Library<br></span><span style="font-size:13px">though.</span></blockquote><div><br></div><div>John F. Kennedy said:  </div><div>"Ask not what your country can do for you — ask what you can do for your country"<br></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:13px"> RAW copy/paste between upstream modules code and your forks. In term<br></span><span style="font-size:13px">of Licensing, I'm even not sure you have the right to do that (I'm not a<br></span><span style="font-size:13px">CLA expert though) but well... in term of authorship and statistics on<br></span><span style="font-size:13px">code, I'm not sure it's fair. Using submodules with custom patches would<br></span><span style="font-size:13px">have been great to respect the authors who created the original code and<br></span><span style="font-size:13px">you could have personalize the manifests.</span></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:13px">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!) </span></blockquote><div><br></div><div>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.</div><div><br></div><div>There only few bugs on <a href="https://bugs.launchpad.net/puppet-openstack/+bugs">https://bugs.launchpad.net/puppet-openstack/+bugs</a>  Though, there is no assignee or milestones. Some bugs can be invalidated. Some bugs require additional info but nobody asked to provide that info.</div><div><br></div><div>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.</div><div><br></div><div><br></div><div>Going back to resolution and action items:</div><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div><br></div><div><br></div></div>