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.
On Thu, Jun 11, 2015 at 8:36 AM, Matthew Mosesohn <mmoses...@mirantis.com> wrote: > Hi Emilien, > > I can see why you might be unhappy with Fuel's actions with regards to > the OpenStack Puppet modules. You could make this argument about many > components in Fuel. The heart of the matter is that we bundle the > upstream OpenStack Puppet modules with all the other modules, > developed both upstream and by Fuel's developers in one single git > repository. This decision, along with all the other decisions to put > Fuel's components under its own repositories, was intended to add > stability and granular control to the product. I'm not saying it's the > most community-oriented approach, but Fuel would have never evolved > and matured without it. The attribution in commits is lost because our > directory namespace differs such that it can't just be merged cleanly. > Revisiting submodules is an option, but it led to maintenance problems > in the past. > Secondly, I'd like to point out that Fuel is not so different from > what other teams are doing. At the Summit, I heard from others who all > maintain internal Gerrits and internal forks of the modules. The > difference is that Fuel is being worked on in the open in StackForge. > Anyone is free to contribute to Fuel as he or she wishes, take our > patches, or review changesets. > > Starting in October 2014, the Fuel team has adopted a policy that we > cannot merge any patches into the core Puppet OpenStack modules of > Fuel without submitting a patch or at least a bug upstream. Our > reviewers block patches consistently. The truth is that the upstream > modules are quite excellent and we don't need to make changes so > often. Our goal is to work with upstream modules or in the issue where > upstream integration is impossible, we place that config in our own > separate modules. > > The point you raised about fixing bugs in Fuel and not in Puppet > OpenStack is definitely valid and something we need to collaborate on. > The first and easiest option when a bug is applicable to both, we > could use Launchpad to assign bugs to both Fuel project and > puppet-$project so it gains visibility. If a bug is discovered in > Puppet OpenStack after it's been reported and/or fixed in Fuel, then > it would be best to ping someone in #fuel-dev on IRC and we can try to > figure out how to get this applied upstream correctly. Our best > results come from fixing upstream and I want to make sure that is > clear. > > If you have specific bugs or commits you'd like to discuss, let's work > them out. I believe I can get the Fuel Library team to agree to do a > walk through all the open bugs in Puppet OpenStack and see if we have > any related fixes or bug reports. > > Best Regards, > Matthew Mosesohn > > On Thu, Jun 11, 2015 at 2:34 PM, Sanjay Upadhyay <san...@gmail.com> wrote: > > +1 for the thread, I would also like to hear from Mirantis on this. > > > > The Fork on fuel/puppet has been actively seen patching and > consolidation.It > > seems like parallel effort why not merge it. > > > > regards > > /sanjay > > > > On Thu, Jun 11, 2015 at 9:12 AM, Emilien Macchi <emil...@redhat.com> > wrote: > >> > >> Hi, > >> > >> Before reading this e-mail, please keep in mind: > >> > >> * I have a lot of admiration for Fuel and since I'm working on OpenStack > >> Installers (at eNovance and now Red Hat), Fuel is something I always > >> consider a good product. > >> * This e-mail is about Fuel and Puppet, nothing about Mirantis. > >> * I'm writing on behalf of my thoughts, and not on our group. > >> * I'm using open mailing-list for open discussion. There is not bad > >> spirit in this e-mail and I want to have a productive thread. > >> > >> I have some concerns I would like to share with you and hopefully find > >> some solutions together. > >> > >> Since I've been working on Puppet OpenStack (2 years now), I see some > >> situations that happen - according to me - too often: > >> > >> * 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. > >> > >> * 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. > >> > >> * 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. > >> > >> Note: you can see that I don't give any example because I'm not here to > >> blame people or judge anyone. > >> > >> So the goal of my e-mail is to open the discussion and have a *real* > >> collaboration between Fuel team which seems to have a lot of good Puppet > >> engineers and Puppet OpenStack team. > >> > >> We had this kind of discussion at the Summit (in Vancouver and also > >> Paris, and even before). Now I would like to officialy know if you are > >> interested or not to be more involved. > >> I'm also open at any feedback about Puppet OpenStack group and if > >> something blocks you to contribute more. > >> > >> We have the same goals, having Puppet modules better. I think it can be > >> win/win: you have less diff with upstream and we have more hands in our > >> module maintenance. > >> Thank you for reading so far, and I'm looking forward to reading from > you. > >> > >> Best regards, > >> -- > >> Emilien Macchi > >> > >> > >> > __________________________________________________________________________ > >> 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 > >> > > > > > > > > -- > > Sanjay Upadhyay > > http://saneax.blogspot.com > > > > > __________________________________________________________________________ > > 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 > > > > __________________________________________________________________________ > 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 >
__________________________________________________________________________ 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
