fuel-dev team mailing list archive

[Dmitry Borodaenko <dborodaenko@xxxxxxxxxxxx>]

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 Borodaenko