fuel-dev team mailing list archive

[Bogdan Dobrelya <bdobrelia@xxxxxxxxxxxx>]

On 03/19/2014 07:45 PM, Dmitry Borodaenko wrote:
> On Wed, Mar 19, 2014 at 4:56 AM, Bogdan Dobrelya <bdobrelia@xxxxxxxxxxxx> wrote:
>> On 03/19/2014 01:31 PM, Dmitry Nikishov wrote:
>>> Actually, zabbix module doesn't come from any upstream repo, it's our
>>> own reimplementation of the module by PL team, which was based on
>>> upstream code. In Zabbix thread it was suggested that we split it into
>>> multiple commits instead of trying to push the whole thing at once.
> 
> It can't be both our own reimplementation and based on upstream code
> at the same time. If it's not rewritten from scratch, you should track
> down the original upstream version and start your commit series from
> that.
> 
>>> It's unclear how it will affect internally developed modules like zabbix
>>> one. Should there be any at all? Or should we make a public repo with
>>> that module first and then try to include it into fuel-library?
> 
> That's a very good question. Personally, I think that we should prefer
> the second option most of the time: create a public repo for the
> standalone module, and use that as upstream for the copy of that
> module in fuel-library. It will make it more likely that this module
> will attract other engineers who will help us find and fix bugs in
> this code, and eventually even add more new features that we'd be able
> to reuse in Fuel.
> 
>> It is also not quite clear how to submit these team-specific changes.
>> 1) E.g. I've submitted the puppet-logstash module from Apollo11 team
>> (Poland) and that module was diverged from the original upstream version
>> by the team. Now we have a two diverged versions - an upstream one and a
>> submitted one.
> 
> I think that you should present each hand-over as a separate commit:
> {original upstream commit} -> {modifications from Apollo11 team} ->
> {modifications to integrate with Fuel}. If you have the commit history
> from Apollo11 and it's not too long, it would be nice to have all of
> it instead of squashing it all into one commit (although if it's more
> than a dozen commits it might now be worth the trouble of pulling each
> commit through Gerrit).
> 
>> 2) Should I submit the diverged commits rebased onto the upstream
>> HEAD/stable version as a separate patchset which depends on the verbatim
>> copy of HEAD/stable patchset? That could be a very bad idea, because
>> rebasing might broke the module completely.
> 
> Yes, I also think that would be a bad idea. Rebase is a kind of a
> change, you don't want to combine that and other changes in a single
> commit, or you loose ability to distinguish what were you changes and
> what changed due to rebase.
> 
>> 3) Should I do the same as (2) but use the common parent commit as an
>> upstream base for verbatim copy instead? Despite on no more rebasing
>> needed, that is not so good idea as well, because it would also
>> complicate the  upstream sync contribution process, if any planned in
>> the future.
> 
> You're not going to be able to kill two rabbits with one stone here.
> Either you significantly diverge from upstream, and keeping up will be
> near impossible, or you keep Fuel specific changes minimal and well
> isolated, and keeping up becomes simple.
> 
> a) If you diverge, the best you can do is submit all your
> non-Fuel-specific improvements to upstream (you will obviously need to
> heavily modify them to decouple from Fuel specific code), and then
> periodically (e.g. once per Fuel release) merge upstream changes back
> into Fuel by hand. The further you deviate, the harder this process
> becomes. It becomes even harder if you don't submit anything to
> upstream, because there will be more changes to hand-port later.
> 
> b) If you can isolate Fuel specific code, keeping up with upstream
> becomes much easier. Create a fork of upstream repo on Github, create
> a fuel branch in that fork, commit all changes for that module to the
> fuel branch before submitting them to fuel-library. Submit non Fuel
> specific changes to upstream (keep them on your fuel branch until they
> are merged). Pulling a new upstream version into fuel-library becomes
> a rebase of your fuel branch of the forked upstream onto the latest
> upstream release, and then copying the result verbatim into
> fuel-library. If Fuel specific code is well isolated, that rebase will
> be trivial.
> 
>> 4) So, looks like the only good option is to accept changes to the
>> puppet modules which are only the sync requests from the upstream (see
>> Openstack projects and Oslo) and never change them locally in the Fuel?
>> But I'm afraid the Fuel puppet modules are not ready yet for such
>> dramatical changes... Looks like we need a kind of Fuel-oslo ;)
> 
> I think we're very far from being able to use this approach.
> 

Dmitry, thank you - that is a good point that makes sense.
But looks like we still have a decision-blocker for introducing any new
modules for puppet in Fuel-library, if one was not synced with the
upstream while in dev / PoC process (i.e. we silently follow the
rejected options (2) and (4) despite on the fact we have near to 90% of
puppet modules in Fuel are far more than 1 year outdated and never
synced with upstream)

Here is an example of such decision blockers:
https://review.openstack.org/#/c/80025/
https://review.openstack.org/#/c/80024/

Hence, lets accept we have a blocker condition in introducing puppet
modules for Fuel, lets decide how to deal with it once again and follow
it in reviews as well.


-- 
Best regards,
Bogdan Dobrelya,
Skype #bogdando_at_yahoo.com
Irc #bogdando