On 06/12/2015 07:58 AM, Bogdan Dobrelya wrote: >> Hi, >> >> Before you read me, please remember I know almost nothing about puppet. :) >> >> On 06/11/2015 11:03 PM, Matt Fischer wrote: >> >> Matt, >> >> I appreciate a lot who you are, and all the help you've given me so far, >> but what you are asking here is wrong. You shouldn't ask Emilien to >> track the work of the Fuel team, and ping them on IRC to contribute >> back. It should be up to them to directly fix upstream *first*, and >> *then* fix back in Fuel. > > This is what we should do, indeed, as a Fuel library team. First, always > get the patch merged upstream, and only next - backport this to Fuel fork. > Ideally, we will next switch to upstream manifests, eventually, so there > would be no need for forks anymore. Sadly, this *never* worked for us > and doesn't work yet as we're, it seems, not ready for this *quite a > long path* of changes landing> So there was a "lazy compromise" and > shortcuts found, which I personally don't like. > > I strongly believe that someday this will start to work for us. And this > is not just a words of hope. Before we did the first > "get-closer-to-upstream" effort, our fork's code base diverge was ~97% > and 0 patches contributed upstream by changes in Fuel library. An > initial sync with upstream modules was the very first step on the right > way. And we're keep doing the best to reduce the code diverge to be > ready to switch upstream modules one day.
I'm actually happy to hear from you, since we were discussing together about that over the last 2 summits, without real plan between both groups. >> >> >> It shouldn't be the way either. The team working on fuel-library should >> be pro-active and doing the contributions, Emilien shouldn't have to > > Nothing to add, you are completely right. > >> discuss a "specific bug of commits". I believe also that Emilien's >> reasoning goes beyond just one or 2 commits, it's a general thinking. >> >> On 06/11/2015 04:36 PM, Matthew Mosesohn wrote: >> >> This isn't the only place where we have a huge git repository doing >> everything. This IMO is a big mistake, which give us more work because >> we have to duplicate what's upstream and constantly rebase. This is yet >> another technical dept... This only works because we have a lot of > > Agree, this makes the technical dept only to grow uncontrollable. Good feedback from the patch's author. > >> Mirantis employee doing the work, so the inefficiency is counter >> balanced by the work force. But as you know, we're always pushing to the >> very limit of everyone to release a new version of MOS and Fuel, so >> maybe now is the time to rethink the way we work. >> >> To move forward, I really believe we (as in: Mirantis) should be: >> 1/ Rework fuel-library to use multiple git for puppet, and maybe work >> out a way to package these individually. >> 2/ Using unmodified version of upstream puppet as much as possible > >> 3/ Work *only* on upstream puppet and not on a separate fork > > I'm all for this option. We have a backlog item to deploy Sounds like another plan here, which sounds great. > OpenStack from upstream packages with Fuel. I'd say this must be done by > upstream puppet manifests as well. Can you clarify what must be done by upstream manifests? >> >> As a lot of the changes that I propose, this would be a one-off painful >> effort to kill this technical dept, but on the long run, we would really >> benefits from such reorganization. >> >> If we don't do the above, it's going to be "business as usual", no mater >> how much efforts Mirantis engineer will put on: the pressure we have to >> deliver Fuel/MOS should shift from the fork to what's upstream. >> >> Cheers, >> >> Thomas Goirand (zigo) > > -- Emilien Macchi
signature.asc
Description: OpenPGP digital signature
__________________________________________________________________________ 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
