<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">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!) However, I don't think that asking puppet openstack devs to ask in the fuel channel if a given bug is fixed in fuel is a very sustainable model. I'm not sure of many projects where the upstream polls downstream to ask whether they've fixed bugs. Can we come up with a way to collaborate more that everyone likes? I think there's a lot of value in it for everyone, we all get a better product out of it.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote"><br></div><div class="gmail_quote">On Thu, Jun 11, 2015 at 8:36 AM, Matthew Mosesohn <span dir="ltr"><<a href="mailto:mmosesohn@mirantis.com" target="_blank">mmosesohn@mirantis.com</a>></span> wrote:<br><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">Hi Emilien,<br>
<br>
I can see why you might be unhappy with Fuel's actions with regards to<br>
the OpenStack Puppet modules. You could make this argument about many<br>
components in Fuel. The heart of the matter is that we bundle the<br>
upstream OpenStack Puppet modules with all the other modules,<br>
developed both upstream and by Fuel's developers in one single git<br>
repository. This decision, along with all the other decisions to put<br>
Fuel's components under its own repositories, was intended to add<br>
stability and granular control to the product. I'm not saying it's the<br>
most community-oriented approach, but Fuel would have never evolved<br>
and matured without it. The attribution in commits is lost because our<br>
directory namespace differs such that it can't just be merged cleanly.<br>
Revisiting submodules is an option, but it led to maintenance problems<br>
in the past. </blockquote><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">
<br>
Secondly, I'd like to point out that Fuel is not so different from<br>
what other teams are doing. At the Summit, I heard from others who all<br>
maintain internal Gerrits and internal forks of the modules. The<br>
difference is that Fuel is being worked on in the open in StackForge.<br>
Anyone is free to contribute to Fuel as he or she wishes, take our<br>
patches, or review changesets.<br></blockquote><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">
Starting in October 2014, the Fuel team has adopted a policy that we<br>
cannot merge any patches into the core Puppet OpenStack modules of<br>
Fuel without submitting a patch or at least a bug upstream. Our<br>
reviewers block patches consistently. The truth is that the upstream<br>
modules are quite excellent and we don't need to make changes so<br>
often. Our goal is to work with upstream modules or in the issue where<br>
upstream integration is impossible, we place that config in our own<br>
separate modules.<br>
<br>
The point you raised about fixing bugs in Fuel and not in Puppet<br>
OpenStack is definitely valid and something we need to collaborate on.<br>
The first and easiest option when a bug is applicable to both, we<br>
could use Launchpad to assign bugs to both Fuel project and<br>
puppet-$project so it gains visibility. If a bug is discovered in<br>
Puppet OpenStack after it's been reported and/or fixed in Fuel, then<br>
it would be best to ping someone in #fuel-dev on IRC and we can try to<br>
figure out how to get this applied upstream correctly. Our best<br>
results come from fixing upstream and I want to make sure that is<br>
clear.<br>
<br>
If you have specific bugs or commits you'd like to discuss, let's work<br>
them out. I believe I can get the Fuel Library team to agree to do a<br>
walk through all the open bugs in Puppet OpenStack and see if we have<br>
any related fixes or bug reports.<br>
<br>
Best Regards,<br>
Matthew Mosesohn<br>
<div><div><br>
On Thu, Jun 11, 2015 at 2:34 PM, Sanjay Upadhyay <<a href="mailto:saneax@gmail.com" target="_blank">saneax@gmail.com</a>> wrote:<br>
> +1 for the thread, I would also like to hear from Mirantis on this.<br>
><br>
> The Fork on fuel/puppet has been actively seen patching and consolidation.It<br>
> seems like parallel effort why not merge it.<br>
><br>
> regards<br>
> /sanjay<br>
><br>
> On Thu, Jun 11, 2015 at 9:12 AM, Emilien Macchi <<a href="mailto:emilien@redhat.com" target="_blank">emilien@redhat.com</a>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> Before reading this e-mail, please keep in mind:<br>
>><br>
>> * I have a lot of admiration for Fuel and since I'm working on OpenStack<br>
>> Installers (at eNovance and now Red Hat), Fuel is something I always<br>
>> consider a good product.<br>
>> * This e-mail is about Fuel and Puppet, nothing about Mirantis.<br>
>> * I'm writing on behalf of my thoughts, and not on our group.<br>
>> * I'm using open mailing-list for open discussion. There is not bad<br>
>> spirit in this e-mail and I want to have a productive thread.<br>
>><br>
>> I have some concerns I would like to share with you and hopefully find<br>
>> some solutions together.<br>
>><br>
>> Since I've been working on Puppet OpenStack (2 years now), I see some<br>
>> situations that happen - according to me - too often:<br>
>><br>
>> * A bug is reported in both Fuel Library and the Puppet module having<br>
>> trouble. A patch is provided in Fuel Library (your fork of Puppet<br>
>> OpenStack modules) but not in Puppet upstream module. That means you fix<br>
>> the bug for Fuel, and not for Puppet OpenStack community. It does not<br>
>> happen all the time but quite often.<br>
>><br>
>> * A patch is submitted in a Puppet module and quite often does not land<br>
>> because there is no activity, no tests or is abandonned later because<br>
>> fixed in Fuel Library. I've noticed the patch is fixed in Fuel Library<br>
>> though.<br>
>><br>
>> * RAW copy/paste between upstream modules code and your forks. In term<br>
>> of Licensing, I'm even not sure you have the right to do that (I'm not a<br>
>> CLA expert though) but well... in term of authorship and statistics on<br>
>> code, I'm not sure it's fair. Using submodules with custom patches would<br>
>> have been great to respect the authors who created the original code and<br>
>> you could have personalize the manifests.<br>
>><br>
>> Note: you can see that I don't give any example because I'm not here to<br>
>> blame people or judge anyone.<br>
>><br>
>> So the goal of my e-mail is to open the discussion and have a *real*<br>
>> collaboration between Fuel team which seems to have a lot of good Puppet<br>
>> engineers and Puppet OpenStack team.<br>
>><br>
>> We had this kind of discussion at the Summit (in Vancouver and also<br>
>> Paris, and even before). Now I would like to officialy know if you are<br>
>> interested or not to be more involved.<br>
>> I'm also open at any feedback about Puppet OpenStack group and if<br>
>> something blocks you to contribute more.<br>
>><br>
>> We have the same goals, having Puppet modules better. I think it can be<br>
>> win/win: you have less diff with upstream and we have more hands in our<br>
>> module maintenance.<br>
>> Thank you for reading so far, and I'm looking forward to reading from you.<br>
>><br>
>> Best regards,<br>
>> --<br>
>> Emilien Macchi<br>
>><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
><br>
><br>
> --<br>
> Sanjay Upadhyay<br>
> <a href="http://saneax.blogspot.com" target="_blank">http://saneax.blogspot.com</a><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>